Messages in this thread | | | Date | Wed, 25 Feb 2009 07:56:32 +0100 | From | Ingo Molnar <> | Subject | Re: [rfc] headers_check cleanups break the whole world |
| |
* 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
| |