[rfc] headers_check cleanups break the whole world

[rfc] headers_check cleanups break the whole world

[Kyle McMartin]

[names omitted to protect the innocent, hpa@ on the CC wrt klibc maybe
  using these? ]

Hi,

Commits like

    headers_check fix: foo.h
    
    fix the following 'make headers_check' warnings:
      usr/include/linux/foo.h:29: include of <linux/types.h> is preferred
      usr/include/linux/foo.h:102: found __[us]{8,16,32,64} type without

have proved problematic...

I've had to point out at least two userspace fixes[1] for a variety of
reasons that these patches exacerbated. Note however that I didn't say
they were wrong.

The reason for this is you cannot intermix glibc header <sys/*.h>
includes with <linux/*.h> includes for most things without defining the
__KERNEL_STRICT_NAMES guard. If you fail to define this, you end up
with multiple definitions of things like dev_t.

Software was able to get by, because things that used the headers, dvb for
example were not getting <linux/types.h> into the include chain, because
they were using <asm/types.h> directly.

I propose we invert that logic, so the presumable libc that makes use of
the <linux/types.h> header can just define that it wants these types.
(test __KERNEL__ as well so the kernel doesn't need a pointless
#define.)

If this isn't tenable, how about moving the {,__}[su]{8,16,32,64}
integer types into their own header, so we can avoid this mess ever
occuring in the future. I'm sure the janitors can have a field day with
that... :)

That said, who exactly is the userspace consumer for those
	typedef __kernel_dev_t	dev_t;
defines? Can we just include them all in #ifdef __KERNEL__?

Thoughts?

cheers, Kyle

1. Ok, one of them was libcap playing utterly stupid games with
<linux/capability.h> and header guards, but it was exacerbated by a
similar patch...

Re: [rfc] headers_check cleanups break the whole world

[H. Peter Anvin]

Kyle McMartin wrote:
> 
> The reason for this is you cannot intermix glibc header <sys/*.h>
> includes with <linux/*.h> includes for most things without defining the
> __KERNEL_STRICT_NAMES guard. If you fail to define this, you end up
> with multiple definitions of things like dev_t.
> 
> Software was able to get by, because things that used the headers, dvb for
> example were not getting <linux/types.h> into the include chain, because
> they were using <asm/types.h> directly.
> 
> I propose we invert that logic, so the presumable libc that makes use of
> the <linux/types.h> header can just define that it wants these types.
> (test __KERNEL__ as well so the kernel doesn't need a pointless
> #define.)
> 

The Right Thing[TM] here is to change the exported headers so that
*only* the __kernel* names are exported, and then remove the
non-__KERNEL_STRICT_NAMES version of <linux/types.h>.  The *only* libc
for which non-__KERNEL_STRICT_NAMES ever made sense was for the
long-since-obsolete libc5.

This, by the way, is not frivolous work.  The work that has been done in
this area already has smoked out a number of bugs where exported headers
were using user space types, which meant they were using the *WRONG
TYPES* on glibc.  Completely.

> If this isn't tenable, how about moving the {,__}[su]{8,16,32,64}
> integer types into their own header, so we can avoid this mess ever
> occuring in the future. I'm sure the janitors can have a field day with
> that... :)
> 
> That said, who exactly is the userspace consumer for those
> 	typedef __kernel_dev_t	dev_t;
> defines? Can we just include them all in #ifdef __KERNEL__? 

That is exactly what we should do.

For what it's worth, not even klibc uses these types.

	-hpa	

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [rfc] headers_check cleanups break the whole world

[Ingo Molnar]

* Kyle McMartin <kyle@infradead.org> wrote:

> [names omitted to protect the innocent, hpa@ on the CC wrt klibc maybe
>   using these? ]
> 
> Hi,
> 
> Commits like
> 
>     headers_check fix: foo.h
>     
>     fix the following 'make headers_check' warnings:
>       usr/include/linux/foo.h:29: include of <linux/types.h> is preferred
>       usr/include/linux/foo.h:102: found __[us]{8,16,32,64} type without
> 
> have proved problematic...
> 
> I've had to point out at least two userspace fixes[1] for a 
> variety of reasons that these patches exacerbated. Note 
> however that I didn't say they were wrong.
>
> The reason for this is you cannot intermix glibc header 
> <sys/*.h> includes with <linux/*.h> includes for most things 
> without defining the __KERNEL_STRICT_NAMES guard. If you fail 
> to define this, you end up with multiple definitions of things 
> like dev_t.
> 
> Software was able to get by, because things that used the 
> headers, dvb for example were not getting <linux/types.h> into 
> the include chain, because they were using <asm/types.h> 
> directly.
> 
> I propose we invert that logic, so the presumable libc that 
> makes use of the <linux/types.h> header can just define that 
> it wants these types. (test __KERNEL__ as well so the kernel 
> doesn't need a pointless
> #define.)
> 
> If this isn't tenable, how about moving the 
> {,__}[su]{8,16,32,64} integer types into their own header, so 
> we can avoid this mess ever occuring in the future. I'm sure 
> the janitors can have a field day with that... :)
> 
> That said, who exactly is the userspace consumer for those
> 	typedef __kernel_dev_t	dev_t;
> defines? Can we just include them all in #ifdef __KERNEL__?
> 
> Thoughts?
> 
> cheers, Kyle
> 
> 1. Ok, one of them was libcap playing utterly stupid games 
> with <linux/capability.h> and header guards, but it was 
> exacerbated by a similar patch...

Well, the intention is to clean up the situation somewhat.

__KERNEL_STRICT_NAMES is a really old construct that has been 
with us forever. It's not widely used ... i dont know how widely 
it's being relied on. Sam, should we get rid of it, or should 
user-space define __KERNEL_STRICT_NAMES in cases the glibc 
definition collides with the kernel's definition?

Note that if user-space is "playing utterly stupid games", it 
can cause trouble no matter what scheme we pick - so we have to 
filter out the reasonable problems that we should and can fix in 
the kernel.

	Ingo

Re: [rfc] headers_check cleanups break the whole world

[H. Peter Anvin]

Ingo Molnar wrote:
> 
> Well, the intention is to clean up the situation somewhat.
> 
> __KERNEL_STRICT_NAMES is a really old construct that has been 
> with us forever. It's not widely used ... i dont know how widely 
> it's being relied on. Sam, should we get rid of it, or should 
> user-space define __KERNEL_STRICT_NAMES in cases the glibc 
> definition collides with the kernel's definition?
> 
> Note that if user-space is "playing utterly stupid games", it 
> can cause trouble no matter what scheme we pick - so we have to 
> filter out the reasonable problems that we should and can fix in 
> the kernel.
> 

__KERNEL_STRICT_NAMES is an anachronism that was put in to not break
libc5.  It has long outlived its usefulness, together with all the other
libc5 support crap in the kernel headers -- which do nothing but make
the kernel headers useless for any sane purposes.

Please let's just axe it.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [rfc] headers_check cleanups break the whole world

[Kyle McMartin]

On Wed, Feb 25, 2009 at 07:56:32AM +0100, Ingo Molnar wrote:
> Note that if user-space is "playing utterly stupid games", it 
> can cause trouble no matter what scheme we pick - so we have to 
> filter out the reasonable problems that we should and can fix in 
> the kernel.
> 

Yeah, sorry, I should have been clearer, libcap does stupid
#define _LINUX_TYPES_H_
typedef unsigned int __u32;
#include <linux/header.h>

Which is just horribly broken when it's included early in a file and
then we try to #include <asm/sigcontext.h> (and doesn't get the rest
of those types since it now includes <linux/types.h> instead of
<asm/types.h>) (coreutils was doing this.)

The real case is something like using the dvb headers, which legitimately
is trying to include both <sys/*.h> and then <linux/dvb/*.h> and expecting
it to work.

The footnote in the prior mail was really just an example of why not
having just the plain __u32 et al types in their own header.

regards, Kyle

Re: [rfc] headers_check cleanups break the whole world

[H. Peter Anvin]

Kyle McMartin wrote:
> 
> Yeah, sorry, I should have been clearer, libcap does stupid
> #define _LINUX_TYPES_H_
> typedef unsigned int __u32;
> #include <linux/header.h>
> 
> Which is just horribly broken when it's included early in a file and
> then we try to #include <asm/sigcontext.h> (and doesn't get the rest
> of those types since it now includes <linux/types.h> instead of
> <asm/types.h>) (coreutils was doing this.)
> 
> The real case is something like using the dvb headers, which legitimately
> is trying to include both <sys/*.h> and then <linux/dvb/*.h> and expecting
> it to work.
> 
> The footnote in the prior mail was really just an example of why not
> having just the plain __u32 et al types in their own header.
> 

Because <linux/types.h> should work just fine once we get rid of the
__KERNEL_STRICT_NAMES idiocy?

FWIW, Arnd Bergmann has been working on exactly this cleanup.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [rfc] headers_check cleanups break the whole world

[Kyle McMartin]

On Tue, Feb 24, 2009 at 11:08:53PM -0800, H. Peter Anvin wrote:
> Because <linux/types.h> should work just fine once we get rid of the
> __KERNEL_STRICT_NAMES idiocy?
> 
> FWIW, Arnd Bergmann has been working on exactly this cleanup.
> 

Ah good, I was about to cook a patch, then I realized there's probably
quite a mess of userspace things depending on, say, sector_t and such.

This is a pretty ugly problem, all things considered. :/

regards, Kyle

Re: [rfc] headers_check cleanups break the whole world

[H. Peter Anvin]

Kyle McMartin wrote:
> On Tue, Feb 24, 2009 at 11:08:53PM -0800, H. Peter Anvin wrote:
>> Because <linux/types.h> should work just fine once we get rid of the
>> __KERNEL_STRICT_NAMES idiocy?
>>
>> FWIW, Arnd Bergmann has been working on exactly this cleanup.
>>
> 
> Ah good, I was about to cook a patch, then I realized there's probably
> quite a mess of userspace things depending on, say, sector_t and such.
> 
> This is a pretty ugly problem, all things considered. :/
> 

Not all that bad, actually.

This is the last patch I've seen on the subject:

http://marc.info/?i=200902051707.55457.arnd@arndb.de

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [rfc] headers_check cleanups break the whole world

[Kyle McMartin]

On Tue, Feb 24, 2009 at 11:16:33PM -0800, H. Peter Anvin wrote:
> Not all that bad, actually.
> 
> This is the last patch I've seen on the subject:
> 
> http://marc.info/?i=200902051707.55457.arnd@arndb.de
> 

Ah, excellent. I must have missed it (looks like Arnd didn't send it to
linux-arch@ as well. :)

Big ACK from me.

regards, Kyle

Re: [rfc] headers_check cleanups break the whole world

[Sam Ravnborg]

> 
> __KERNEL_STRICT_NAMES is a really old construct that has been 
> with us forever. It's not widely used ... i dont know how widely 
> it's being relied on. Sam, should we get rid of it, or should 
> user-space define __KERNEL_STRICT_NAMES in cases the glibc 
> definition collides with the kernel's definition?

hpa already answered this question and he knows
the userland<->kernel stuff better than I do.

IMO the best thing would be that Arnd rebased his original patch
and we get that rewieved and in the end applied.

	Sam

[PATCH] Make exported headers use strict posix types

[Arnd Bergmann]

A number of standard posix types are used in exported headers, which
is not allowed if __STRICT_KERNEL_NAMES is defined. In order to
get rid of the non-__STRICT_KERNEL_NAMES part and to make sane headers
the default, we have to change them all to safe types.

There are also still some leftovers in reiserfs_fs.h, elfcore.h
and coda.h, but these files have not compiled in user space for
a long time.

This leaves out the various integer types (u_int32_t, uint32_t, u32,
uint and the signed and 8/16/64 bit variants thereof), which we may
want to do in an automated script instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
On Wednesday 25 February 2009, Kyle McMartin wrote:
> On Tue, Feb 24, 2009 at 11:16:33PM -0800, H. Peter Anvin wrote:
> > Not all that bad, actually.
> > 
> > This is the last patch I've seen on the subject:
> > 
> > http://marc.info/?i=200902051707.55457.arnd@arndb.de
> > 
> 
> Ah, excellent. I must have missed it (looks like Arnd didn't send it to
> linux-arch@ as well. :)

This is my previous patch, ported to today's git. It's my last day
before my vacation, so I can't do the usual testing etc. on it.
Hopefully somebody else can take care of this.

	Arnd <><

diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h
index b847741..4d3e483 100644
--- a/include/asm-generic/fcntl.h
+++ b/include/asm-generic/fcntl.h
@@ -117,9 +117,9 @@
 struct flock {
 	short	l_type;
 	short	l_whence;
-	off_t	l_start;
-	off_t	l_len;
-	pid_t	l_pid;
+	__kernel_off_t	l_start;
+	__kernel_off_t	l_len;
+	__kernel_pid_t	l_pid;
 	__ARCH_FLOCK_PAD
 };
 #endif
@@ -140,9 +140,9 @@ struct flock {
 struct flock64 {
 	short  l_type;
 	short  l_whence;
-	loff_t l_start;
-	loff_t l_len;
-	pid_t  l_pid;
+	__kernel_loff_t l_start;
+	__kernel_loff_t l_len;
+	__kernel_pid_t  l_pid;
 	__ARCH_FLOCK64_PAD
 };
 #endif
diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
index 9695701..35f75a3 100644
--- a/include/asm-generic/siginfo.h
+++ b/include/asm-generic/siginfo.h
@@ -23,7 +23,7 @@ typedef union sigval {
 #endif
 
 #ifndef __ARCH_SI_UID_T
-#define __ARCH_SI_UID_T	uid_t
+#define __ARCH_SI_UID_T	__kernel_uid_t
 #endif
 
 /*
@@ -47,13 +47,13 @@ typedef struct siginfo {
 
 		/* kill() */
 		struct {
-			pid_t _pid;		/* sender's pid */
+			__kernel_pid_t _pid;	/* sender's pid */
 			__ARCH_SI_UID_T _uid;	/* sender's uid */
 		} _kill;
 
 		/* POSIX.1b timers */
 		struct {
-			timer_t _tid;		/* timer id */
+			__kernel_timer_t _tid;	/* timer id */
 			int _overrun;		/* overrun count */
 			char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
 			sigval_t _sigval;	/* same as below */
@@ -62,18 +62,18 @@ typedef struct siginfo {
 
 		/* POSIX.1b signals */
 		struct {
-			pid_t _pid;		/* sender's pid */
+			__kernel_pid_t _pid;	/* sender's pid */
 			__ARCH_SI_UID_T _uid;	/* sender's uid */
 			sigval_t _sigval;
 		} _rt;
 
 		/* SIGCHLD */
 		struct {
-			pid_t _pid;		/* which child */
+			__kernel_pid_t _pid;	/* which child */
 			__ARCH_SI_UID_T _uid;	/* sender's uid */
 			int _status;		/* exit code */
-			clock_t _utime;
-			clock_t _stime;
+			__kernel_clock_t _utime;
+			__kernel_clock_t _stime;
 		} _sigchld;
 
 		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
diff --git a/include/linux/agpgart.h b/include/linux/agpgart.h
index 110c600..f6778ec 100644
--- a/include/linux/agpgart.h
+++ b/include/linux/agpgart.h
@@ -77,20 +77,20 @@ typedef struct _agp_setup {
  * The "prot" down below needs still a "sleep" flag somehow ...
  */
 typedef struct _agp_segment {
-	off_t pg_start;		/* starting page to populate    */
-	size_t pg_count;	/* number of pages              */
-	int prot;		/* prot flags for mmap          */
+	__kernel_off_t pg_start;	/* starting page to populate    */
+	__kernel_size_t pg_count;	/* number of pages              */
+	int prot;			/* prot flags for mmap          */
 } agp_segment;
 
 typedef struct _agp_region {
-	pid_t pid;		/* pid of process               */
-	size_t seg_count;	/* number of segments           */
+	__kernel_pid_t pid;		/* pid of process       */
+	__kernel_size_t seg_count;	/* number of segments   */
 	struct _agp_segment *seg_list;
 } agp_region;
 
 typedef struct _agp_allocate {
 	int key;		/* tag of allocation            */
-	size_t pg_count;	/* number of pages              */
+	__kernel_size_t pg_count;/* number of pages             */
 	__u32 type;		/* 0 == normal, other devspec   */
    	__u32 physical;         /* device specific (some devices  
 				 * need a phys address of the     
@@ -100,7 +100,7 @@ typedef struct _agp_allocate {
 
 typedef struct _agp_bind {
 	int key;		/* tag of allocation            */
-	off_t pg_start;		/* starting page to populate    */
+	__kernel_off_t pg_start;/* starting page to populate    */
 } agp_bind;
 
 typedef struct _agp_unbind {
diff --git a/include/linux/cn_proc.h b/include/linux/cn_proc.h
index 1c86d65..b8125b2 100644
--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -65,20 +65,20 @@ struct proc_event {
 		} ack;
 
 		struct fork_proc_event {
-			pid_t parent_pid;
-			pid_t parent_tgid;
-			pid_t child_pid;
-			pid_t child_tgid;
+			__kernel_pid_t parent_pid;
+			__kernel_pid_t parent_tgid;
+			__kernel_pid_t child_pid;
+			__kernel_pid_t child_tgid;
 		} fork;
 
 		struct exec_proc_event {
-			pid_t process_pid;
-			pid_t process_tgid;
+			__kernel_pid_t process_pid;
+			__kernel_pid_t process_tgid;
 		} exec;
 
 		struct id_proc_event {
-			pid_t process_pid;
-			pid_t process_tgid;
+			__kernel_pid_t process_pid;
+			__kernel_pid_t process_tgid;
 			union {
 				__u32 ruid; /* task uid */
 				__u32 rgid; /* task gid */
@@ -90,8 +90,8 @@ struct proc_event {
 		} id;
 
 		struct exit_proc_event {
-			pid_t process_pid;
-			pid_t process_tgid;
+			__kernel_pid_t process_pid;
+			__kernel_pid_t process_tgid;
 			__u32 exit_code, exit_signal;
 		} exit;
 	} event_data;
diff --git a/include/linux/coda_psdev.h b/include/linux/coda_psdev.h
index 07ae8f8..ebdc055 100644
--- a/include/linux/coda_psdev.h
+++ b/include/linux/coda_psdev.h
@@ -6,6 +6,7 @@
 #define CODA_PSDEV_MAJOR 67
 #define MAX_CODADEVS  5	   /* how many do we allow */
 
+#ifdef __KERNEL__
 struct kstatfs;
 
 /* communication pending/processing queues */
@@ -89,4 +90,5 @@ struct upc_req {
 
 extern struct venus_comm coda_comms[];
 
+#endif /* __KERNEL__ */
 #endif
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 0999271..f6dcc29 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
 
 /* GCC 4.1.[01] miscompiles __weak */
 #if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
-# error Your version of gcc miscompiles the __weak directive
+// # error Your version of gcc miscompiles the __weak directive
 #endif
 
 #define __used			__attribute__((__used__))
diff --git a/include/linux/cyclades.h b/include/linux/cyclades.h
index d06fbf2..788850b 100644
--- a/include/linux/cyclades.h
+++ b/include/linux/cyclades.h
@@ -82,9 +82,9 @@ struct cyclades_monitor {
  * open)
  */
 struct cyclades_idle_stats {
-    time_t	   in_use;	/* Time device has been in use (secs) */
-    time_t	   recv_idle;	/* Time since last char received (secs) */
-    time_t	   xmit_idle;	/* Time since last char transmitted (secs) */
+    __kernel_time_t in_use;	/* Time device has been in use (secs) */
+    __kernel_time_t recv_idle;	/* Time since last char received (secs) */
+    __kernel_time_t xmit_idle;	/* Time since last char transmitted (secs) */
     unsigned long  recv_bytes;	/* Bytes received */
     unsigned long  xmit_bytes;	/* Bytes transmitted */
     unsigned long  overruns;	/* Input overruns */
diff --git a/include/linux/dvb/video.h b/include/linux/dvb/video.h
index bd49c3e..ee5d2df 100644
--- a/include/linux/dvb/video.h
+++ b/include/linux/dvb/video.h
@@ -137,7 +137,7 @@ struct video_event {
 #define VIDEO_EVENT_FRAME_RATE_CHANGED	2
 #define VIDEO_EVENT_DECODER_STOPPED 	3
 #define VIDEO_EVENT_VSYNC 		4
-	time_t timestamp;
+	__kernel_time_t timestamp;
 	union {
 		video_size_t size;
 		unsigned int frame_rate;	/* in frames per 1000sec */
diff --git a/include/linux/if_pppol2tp.h b/include/linux/if_pppol2tp.h
index c7a6688..3a14b08 100644
--- a/include/linux/if_pppol2tp.h
+++ b/include/linux/if_pppol2tp.h
@@ -26,7 +26,7 @@
  */
 struct pppol2tp_addr
 {
-	pid_t	pid;			/* pid that owns the fd.
+	__kernel_pid_t	pid;		/* pid that owns the fd.
 					 * 0 => current */
 	int	fd;			/* FD of UDP socket to use */
 
diff --git a/include/linux/mroute6.h b/include/linux/mroute6.h
index 5375fac..43dc97e 100644
--- a/include/linux/mroute6.h
+++ b/include/linux/mroute6.h
@@ -65,7 +65,7 @@ struct mif6ctl {
 	mifi_t	mif6c_mifi;		/* Index of MIF */
 	unsigned char mif6c_flags;	/* MIFF_ flags */
 	unsigned char vifc_threshold;	/* ttl limit */
-	u_short	 mif6c_pifi;		/* the index of the physical IF */
+	__u16	 mif6c_pifi;		/* the index of the physical IF */
 	unsigned int vifc_rate_limit;	/* Rate limiter values (NI) */
 };
 
diff --git a/include/linux/netfilter_ipv4/ipt_owner.h b/include/linux/netfilter_ipv4/ipt_owner.h
index 92f4bda..60e941f 100644
--- a/include/linux/netfilter_ipv4/ipt_owner.h
+++ b/include/linux/netfilter_ipv4/ipt_owner.h
@@ -9,10 +9,10 @@
 #define IPT_OWNER_COMM	0x10
 
 struct ipt_owner_info {
-    uid_t uid;
-    gid_t gid;
-    pid_t pid;
-    pid_t sid;
+    __kernel_uid_t uid;
+    __kernel_gid_t gid;
+    __kernel_pid_t pid;
+    __kernel_pid_t sid;
     char comm[16];
     u_int8_t match, invert;	/* flags */
 };
diff --git a/include/linux/netfilter_ipv6/ip6t_owner.h b/include/linux/netfilter_ipv6/ip6t_owner.h
index 19937da..dc2cbcb 100644
--- a/include/linux/netfilter_ipv6/ip6t_owner.h
+++ b/include/linux/netfilter_ipv6/ip6t_owner.h
@@ -8,10 +8,10 @@
 #define IP6T_OWNER_SID	0x08
 
 struct ip6t_owner_info {
-    uid_t uid;
-    gid_t gid;
-    pid_t pid;
-    pid_t sid;
+    __kernel_uid_t uid;
+    __kernel_gid_t gid;
+    __kernel_pid_t pid;
+    __kernel_pid_t sid;
     u_int8_t match, invert;	/* flags */
 };
 
diff --git a/include/linux/ppp_defs.h b/include/linux/ppp_defs.h
index 1c866bd..0f93ed6 100644
--- a/include/linux/ppp_defs.h
+++ b/include/linux/ppp_defs.h
@@ -177,8 +177,8 @@ struct ppp_comp_stats {
  * the last NP packet was sent or received.
  */
 struct ppp_idle {
-    time_t xmit_idle;		/* time since last NP packet sent */
-    time_t recv_idle;		/* time since last NP packet received */
+    __kernel_time_t xmit_idle;	/* time since last NP packet sent */
+    __kernel_time_t recv_idle;	/* time since last NP packet received */
 };
 
 #endif /* _PPP_DEFS_H_ */
diff --git a/include/linux/suspend_ioctls.h b/include/linux/suspend_ioctls.h
index 2c6faec..40d4605 100644
--- a/include/linux/suspend_ioctls.h
+++ b/include/linux/suspend_ioctls.h
@@ -7,8 +7,8 @@
  * SNAPSHOT_SET_SWAP_AREA ioctl
  */
 struct resume_swap_area {
-	loff_t offset;
-	u_int32_t dev;
+	__kernel_loff_t offset;
+	__u32 dev;
 } __attribute__((packed));
 
 #define SNAPSHOT_IOC_MAGIC	'3'
@@ -20,13 +20,13 @@ struct resume_swap_area {
 #define SNAPSHOT_S2RAM			_IO(SNAPSHOT_IOC_MAGIC, 11)
 #define SNAPSHOT_SET_SWAP_AREA		_IOW(SNAPSHOT_IOC_MAGIC, 13, \
 							struct resume_swap_area)
-#define SNAPSHOT_GET_IMAGE_SIZE		_IOR(SNAPSHOT_IOC_MAGIC, 14, loff_t)
+#define SNAPSHOT_GET_IMAGE_SIZE		_IOR(SNAPSHOT_IOC_MAGIC, 14, __kernel_loff_t)
 #define SNAPSHOT_PLATFORM_SUPPORT	_IO(SNAPSHOT_IOC_MAGIC, 15)
 #define SNAPSHOT_POWER_OFF		_IO(SNAPSHOT_IOC_MAGIC, 16)
 #define SNAPSHOT_CREATE_IMAGE		_IOW(SNAPSHOT_IOC_MAGIC, 17, int)
 #define SNAPSHOT_PREF_IMAGE_SIZE	_IO(SNAPSHOT_IOC_MAGIC, 18)
-#define SNAPSHOT_AVAIL_SWAP_SIZE	_IOR(SNAPSHOT_IOC_MAGIC, 19, loff_t)
-#define SNAPSHOT_ALLOC_SWAP_PAGE	_IOR(SNAPSHOT_IOC_MAGIC, 20, loff_t)
+#define SNAPSHOT_AVAIL_SWAP_SIZE	_IOR(SNAPSHOT_IOC_MAGIC, 19, __kernel_loff_t)
+#define SNAPSHOT_ALLOC_SWAP_PAGE	_IOR(SNAPSHOT_IOC_MAGIC, 20, __kernel_loff_t)
 #define SNAPSHOT_IOC_MAXNR	20
 
 #endif /* _LINUX_SUSPEND_IOCTLS_H */
diff --git a/include/linux/time.h b/include/linux/time.h
index fbbd2a1..242f624 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -12,14 +12,14 @@
 #ifndef _STRUCT_TIMESPEC
 #define _STRUCT_TIMESPEC
 struct timespec {
-	time_t	tv_sec;		/* seconds */
-	long	tv_nsec;	/* nanoseconds */
+	__kernel_time_t	tv_sec;			/* seconds */
+	long		tv_nsec;		/* nanoseconds */
 };
 #endif
 
 struct timeval {
-	time_t		tv_sec;		/* seconds */
-	suseconds_t	tv_usec;	/* microseconds */
+	__kernel_time_t		tv_sec;		/* seconds */
+	__kernel_suseconds_t	tv_usec;	/* microseconds */
 };
 
 struct timezone {
diff --git a/include/linux/times.h b/include/linux/times.h
index e2d3020..87b6261 100644
--- a/include/linux/times.h
+++ b/include/linux/times.h
@@ -4,10 +4,10 @@
 #include <linux/types.h>
 
 struct tms {
-	clock_t tms_utime;
-	clock_t tms_stime;
-	clock_t tms_cutime;
-	clock_t tms_cstime;
+	__kernel_clock_t tms_utime;
+	__kernel_clock_t tms_stime;
+	__kernel_clock_t tms_cutime;
+	__kernel_clock_t tms_cstime;
 };
 
 #endif
diff --git a/include/linux/utime.h b/include/linux/utime.h
index 640be6a..5cdf673 100644
--- a/include/linux/utime.h
+++ b/include/linux/utime.h
@@ -4,8 +4,8 @@
 #include <linux/types.h>
 
 struct utimbuf {
-	time_t actime;
-	time_t modtime;
+	__kernel_time_t actime;
+	__kernel_time_t modtime;
 };
 
 #endif
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 52f3abd..a58fe2b 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -58,7 +58,7 @@ struct xfrm_selector
 	__u8	prefixlen_s;
 	__u8	proto;
 	int	ifindex;
-	uid_t	user;
+	__kernel_uid_t	user;
 };
 
 #define XFRM_INF (~(__u64)0)
diff --git a/include/mtd/mtd-abi.h b/include/mtd/mtd-abi.h
index c6c61cd..fb67201 100644
--- a/include/mtd/mtd-abi.h
+++ b/include/mtd/mtd-abi.h
@@ -84,8 +84,8 @@ struct otp_info {
 #define MEMGETREGIONINFO	_IOWR('M', 8, struct region_info_user)
 #define MEMSETOOBSEL		_IOW('M', 9, struct nand_oobinfo)
 #define MEMGETOOBSEL		_IOR('M', 10, struct nand_oobinfo)
-#define MEMGETBADBLOCK		_IOW('M', 11, loff_t)
-#define MEMSETBADBLOCK		_IOW('M', 12, loff_t)
+#define MEMGETBADBLOCK		_IOW('M', 11, __kernel_loff_t)
+#define MEMSETBADBLOCK		_IOW('M', 12, __kernel_loff_t)
 #define OTPSELECT		_IOR('M', 13, int)
 #define OTPGETREGIONCOUNT	_IOW('M', 14, int)
 #define OTPGETREGIONINFO	_IOW('M', 15, struct otp_info)
diff --git a/include/sound/asound.h b/include/sound/asound.h
index 1c02ed1..16684c5 100644
--- a/include/sound/asound.h
+++ b/include/sound/asound.h
@@ -385,7 +385,7 @@ struct snd_pcm_sw_params {
 
 struct snd_pcm_channel_info {
 	unsigned int channel;
-	off_t offset;			/* mmap offset */
+	__kernel_off_t offset;		/* mmap offset */
 	unsigned int first;		/* offset to first sample in bits */
 	unsigned int step;		/* samples distance in bits */
 };
@@ -789,7 +789,7 @@ struct snd_ctl_elem_info {
 	snd_ctl_elem_type_t type;	/* R: value type - SNDRV_CTL_ELEM_TYPE_* */
 	unsigned int access;		/* R: value access (bitmask) - SNDRV_CTL_ELEM_ACCESS_* */
 	unsigned int count;		/* count of values */
-	pid_t owner;			/* owner's PID of this control */
+	__kernel_pid_t owner;		/* owner's PID of this control */
 	union {
 		struct {
 			long min;		/* R: minimum value */

Re: [PATCH] Make exported headers use strict posix types

[Sam Ravnborg]

On Wed, Feb 25, 2009 at 07:17:47PM +0100, Arnd Bergmann wrote:
> A number of standard posix types are used in exported headers, which
> is not allowed if __STRICT_KERNEL_NAMES is defined. In order to
> get rid of the non-__STRICT_KERNEL_NAMES part and to make sane headers
> the default, we have to change them all to safe types.
> 
> There are also still some leftovers in reiserfs_fs.h, elfcore.h
> and coda.h, but these files have not compiled in user space for
> a long time.
> 
> This leaves out the various integer types (u_int32_t, uint32_t, u32,
> uint and the signed and 8/16/64 bit variants thereof), which we may
> want to do in an automated script instead.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> 
> This is my previous patch, ported to today's git. It's my last day
> before my vacation, so I can't do the usual testing etc. on it.
> Hopefully somebody else can take care of this.

I hesitate to put it in kbuild.git... Any better place?

> diff --git a/include/linux/coda_psdev.h b/include/linux/coda_psdev.h
> index 07ae8f8..ebdc055 100644
> --- a/include/linux/coda_psdev.h
> +++ b/include/linux/coda_psdev.h
> @@ -6,6 +6,7 @@
>  #define CODA_PSDEV_MAJOR 67
>  #define MAX_CODADEVS  5	   /* how many do we allow */
>  
> +#ifdef __KERNEL__
>  struct kstatfs;
>  
>  /* communication pending/processing queues */
> @@ -89,4 +90,5 @@ struct upc_req {
>  
>  extern struct venus_comm coda_comms[];
>  
> +#endif /* __KERNEL__ */
>  #endif

Does this change really belong in this patchset?

> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 0999271..f6dcc29 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -4,7 +4,7 @@
>  
>  /* GCC 4.1.[01] miscompiles __weak */
>  #if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
> -# error Your version of gcc miscompiles the __weak directive
> +// # error Your version of gcc miscompiles the __weak directive
>  #endif
>  
>  #define __used			__attribute__((__used__))

Yes - I can build kernels again. But I think we should skip this change..

> diff --git a/include/linux/mroute6.h b/include/linux/mroute6.h
> index 5375fac..43dc97e 100644
> --- a/include/linux/mroute6.h
> +++ b/include/linux/mroute6.h
> @@ -65,7 +65,7 @@ struct mif6ctl {
>  	mifi_t	mif6c_mifi;		/* Index of MIF */
>  	unsigned char mif6c_flags;	/* MIFF_ flags */
>  	unsigned char vifc_threshold;	/* ttl limit */
> -	u_short	 mif6c_pifi;		/* the index of the physical IF */
> +	__u16	 mif6c_pifi;		/* the index of the physical IF */
>  	unsigned int vifc_rate_limit;	/* Rate limiter values (NI) */
>  };
>  
This change looks correct - but I assume this is a separate patch.

Rest looks good.

	Sam

Re: [PATCH] Make exported headers use strict posix types

[Arnd Bergmann]

On Wednesday 25 February 2009, Sam Ravnborg wrote:

 
> Does this change really belong in this patchset?
 
> Yes - I can build kernels again. But I think we should skip this change..

> This change looks correct - but I assume this is a separate patch.
> 
> Rest looks good.

Agreed on all points, I had the changes sitting in a dirty git tree
and got sloppy. Thanks for looking through it!

	Arnd <><

Re: [PATCH] Make exported headers use strict posix types

[Arnd Bergmann]

On Wednesday 25 February 2009, Sam Ravnborg wrote:
> > diff --git a/include/linux/mroute6.h b/include/linux/mroute6.h
> > index 5375fac..43dc97e 100644
> > --- a/include/linux/mroute6.h
> > +++ b/include/linux/mroute6.h
> > @@ -65,7 +65,7 @@ struct mif6ctl {
> >       mifi_t  mif6c_mifi;             /* Index of MIF */
> >       unsigned char mif6c_flags;      /* MIFF_ flags */
> >       unsigned char vifc_threshold;   /* ttl limit */
> > -     u_short  mif6c_pifi;            /* the index of the physical IF */
> > +     __u16    mif6c_pifi;            /* the index of the physical IF */
> >       unsigned int vifc_rate_limit;   /* Rate limiter values (NI) */
> >  };
> >  
> This change looks correct - but I assume this is a separate patch.
> 

Actually, this change does belong in here: This is the only user of u_short
in exported headers, and nothing uses u_char, u_int or u_long, so it gets
rid of a whole class of types. The only questionable types left after this
are the standard stdint.h types, many of which are probably legitimate:

grep '\<\(u_\|u\|\)int\(8\|16\|32\|64\)_t\>' obj/usr/include/ -r | \
		 cut -f 1 -d: | uniq -c | grep -v netfilter
      2 obj/usr/include/linux/atmlec.h
     13 obj/usr/include/linux/jffs2.h
      1 obj/usr/include/linux/ivtvfb.h
     12 obj/usr/include/linux/types.h
    121 obj/usr/include/linux/pfkeyv2.h
     13 obj/usr/include/linux/ip_vs.h
     21 obj/usr/include/linux/dm-ioctl.h
      4 obj/usr/include/linux/cm4000_cs.h
      8 obj/usr/include/linux/dlm_netlink.h
      2 obj/usr/include/linux/selinux_netlink.h
     11 obj/usr/include/linux/dvb/video.h
      1 obj/usr/include/linux/dvb/audio.h
     22 obj/usr/include/linux/atmmpc.h
     23 obj/usr/include/linux/coda.h
      1 obj/usr/include/linux/matroxfb.h
     13 obj/usr/include/linux/if_arcnet.h
      8 obj/usr/include/drm/mga_drm.h
      1 obj/usr/include/drm/radeon_drm.h
     20 obj/usr/include/drm/via_drm.h
      9 obj/usr/include/drm/drm.h
     74 obj/usr/include/drm/drm_mode.h
     69 obj/usr/include/drm/i915_drm.h
     15 obj/usr/include/mtd/nftl-user.h
      2 obj/usr/include/mtd/jffs2-user.h
     18 obj/usr/include/mtd/inftl-user.h
     32 obj/usr/include/mtd/mtd-abi.h
     35 obj/usr/include/mtd/ubi-user.h
      4 obj/usr/include/sound/emu10k1.h
      1 obj/usr/include/sound/asound.h

	Arnd <><

Re: [PATCH] Make exported headers use strict posix types

[H. Peter Anvin]

Arnd Bergmann wrote:
> 
> Actually, this change does belong in here: This is the only user of u_short
> in exported headers, and nothing uses u_char, u_int or u_long, so it gets
> rid of a whole class of types. The only questionable types left after this
> are the standard stdint.h types, many of which are probably legitimate:
> 

Not legitimate in *exported* headers.

	-hpa

Re: [PATCH] Make exported headers use strict posix types

[David Woodhouse]

On Wed, 2009-02-25 at 14:07 -0800, H. Peter Anvin wrote:
> Arnd Bergmann wrote:
> > 
> > Actually, this change does belong in here: This is the only user of u_short
> > in exported headers, and nothing uses u_char, u_int or u_long, so it gets
> > rid of a whole class of types. The only questionable types left after this
> > are the standard stdint.h types, many of which are probably legitimate:
> > 
> 
> Not legitimate in *exported* headers.

Not in the ones which might be included implicitly by glibc, perhaps --
but other non-POSIX headers are perfectly entitled to require C standard
types, surely?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [PATCH] Make exported headers use strict posix types

[H. Peter Anvin]

Sam Ravnborg wrote:
>>
>> This is my previous patch, ported to today's git. It's my last day
>> before my vacation, so I can't do the usual testing etc. on it.
>> Hopefully somebody else can take care of this.
> 
> I hesitate to put it in kbuild.git... Any better place?
> 

I'll put it in tip:core/headers-fixes.

	-hpa

Re: [PATCH] Make exported headers use strict posix types

[H. Peter Anvin]

David Woodhouse wrote:
>> Not legitimate in *exported* headers.
> 
> Not in the ones which might be included implicitly by glibc, perhaps --
> but other non-POSIX headers are perfectly entitled to require C standard
> types, surely?

It doesn't make any sense, though, when there is a straighforward way to 
deal without.

Now, for source code maintainability reasons I still believe this should 
be done mechanically instead of having to edit the source all over the 
place.

	-hpa

Re: [PATCH] Make exported headers use strict posix types

[Arnd Bergmann]

On Thursday 26 February 2009, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >>
> >> This is my previous patch, ported to today's git. It's my last day
> >> before my vacation, so I can't do the usual testing etc. on it.
> >> Hopefully somebody else can take care of this.
> > 
> > I hesitate to put it in kbuild.git... Any better place?
> > 
> 
> I'll put it in tip:core/headers-fixes.

Just in the minute I notice a bug :(

Unfortunately, I mistakenly replaced uid_t with __kernel_uid_t when
it had to be __kernel_uid32_t. New series follows, including the
changes for all integer types.

	Arnd <><

Re: [PATCH] Make exported headers use strict posix types

[H. Peter Anvin]

Arnd Bergmann wrote:
> 
> Just in the minute I notice a bug :(
> 
> Unfortunately, I mistakenly replaced uid_t with __kernel_uid_t when
> it had to be __kernel_uid32_t. New series follows, including the
> changes for all integer types.
> 

S'okay... it's easy enough to back out at this time.

	-hpa