Re: [PATCH] mips: Remove posix_types.h include from sigcontext.h

[Maciej W. Rozycki]

On Wed, 28 Aug 2024, Xi Ruoyao wrote:

> It seems only a relict: in a Linux 2.6.11-rc2 patch [1] the
> linux/types.h include was unexplainedly changed to a linux/posix_types.h
> include.  I can only assume it was just an error.  Finally headers_check
> complained "found __[us]{8,16,32,64} type without #include
> <linux/types.h>" and commit ae612fb05b0f ("headers_check fix: mips,
> sigcontext.h") added back the linux/types.h include, but it didn't
> remove the posix_types.h include.

 The original LMO change was this:

commit 1dc129df74a76ee16593c9220c3f7289ee627d03
Author: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
Date:   Sat Dec 18 01:09:29 2004 +0000

    Don't pull <linux/types.h> into userspace.

diff --git a/include/asm-mips/sigcontext.h b/include/asm-mips/sigcontext.h
index 844879d63b77..18939e84b6f2 100644
--- a/include/asm-mips/sigcontext.h
+++ b/include/asm-mips/sigcontext.h
@@ -41,8 +41,6 @@ struct sigcontext {
                                                                                 
 #if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32
 
-#include <linux/types.h>
-
 /*
  * Keep this struct definition in sync with the sigcontext fragment
  * in arch/mips/tools/offset.c
@@ -66,6 +64,9 @@ struct sigcontext {
 };
 
 #ifdef __KERNEL__
+
+#include <linux/posix_types.h>
+
 struct sigcontext32 {
 	__u32	sc_regmask;		/* Unused */
 	__u32	sc_status;

so not without explanation and clearly to address a userland compilation 
issue.  It seems that the original directive should have just been moved 
into the __KERNEL__ part without changing the file included though.

 So commit ae612fb05b0f was wrong too in that it should have just changed 
the directive in place rather than adding #include <linux/types.h> at the 
top, as it just brought the issue back that commit 1dc129df74a7 attempted 
to address.

 Meanwhile there was commit 269dd2b2526d, which messed things up further, 
as it should have used `unsigned long long' rather than `__u64' as the 
64-bit type (and leave `unsigned int' intact), so commit ae612fb05b0f 
couldn't actually have done a better fix without correcting commit 
269dd2b2526d first.

 We have since developed UAPI headers, so the issue of the userland use of 
<linux/types.h> has gone, but still I think we ought to clean up the mess 
in this header by switching back to standard ISO C `unsigned long long' 
and `unsigned int' types for members of 64-bit `struct sigcontext', and 
then the inclusion of <linux/types.h> can go too.

 That written I think your change makes sense by itself, but I suggest 
that you update the description and summarise the findings given here.  
I'm not sure if a copy of the LMO repo is available online at this time 
though.

  Maciej