Re: [rfc] headers_check cleanups break the whole world

[Ingo Molnar <mingo@elte.hu>]

* 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