Messages in this thread | | | Date | Tue, 24 Feb 2009 22:25:53 -0500 | From | Kyle McMartin <> | Subject | [rfc] headers_check cleanups break the whole world |
| |
[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...
| |