[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] headers_check cleanups break the whole world
    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.


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

     \ /
      Last update: 2009-02-25 07:31    [W:0.021 / U:80.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site