lkml.org 
[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-02-25 07:59    [W:0.103 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site