[lkml]   [2006]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: header cleanup and install
    On Sun, 2006-06-04 at 13:50 -0700, Andrew Morton wrote:
    > git-hdrcleanup.patch
    > git-hdrinstall.patch
    > This is Dave Woodhouse's work cleaning up the kernel headers and adding a
    > `make headerinstall' target which automates the exporting of kernel
    > headers as a userspace-usable package.

    More specifically:

    git-hdrcleanup is simple and boring janitorial stuff in headers --
    nothing particularly new and exciting. Mostly it's just moving stuff
    that shouldn't be user-visible inside existing instances of #ifdef
    __KERNEL__ -- it doesn't even add many new ifdefs. A large chunk of it
    is just removing the superfluous #include <linux/config.h> from every

    The only bit that's even vaguely interesting, if you're _desperate_ to
    find something exciting in it, is the fact that I hid the broken
    _syscallX macros from asm-*/unistd.h inside #ifdef __KERNEL__. They're
    broken for 64-bit syscall arguments on architectures like MIPS, they
    were even broken for PIC code on i386. Not only were they broken, but
    also the kernel headers are _not_ a library of random crap for userspace
    to use. Glibc doesn't use them, klibc doesn't use them, and dietlibc
    folks were working on not using them last time I checked.

    git-hdrinstall is just the 'make headers_install' thing, based on an
    original implementation by Arnd Bergmann. It takes the set of headers
    which are at all suitable for userspace and exports them with unifdef.
    The idea is that distributions can have a _consistent_ set of headers to
    build stuff like glibc and system tools against, rather than the horrid
    mess we have now. Those files can also be diffed from one release to the
    next, and we have a decent chance of actually _seeing_ what changed,
    without all the noise. Having done that diff on my last few updates, it
    does actually seem to work like that in practice.

    > That being said, it's relatively costly to carry such extensive patches
    > in -mm for long periods, so I'd ask Linus and the distro people to work
    > out what we want to do here promptly, please.

    The result of this is already shipping in Fedora rawhide, and it's a
    godsend. I haven't heard much from the relevant package maintainers in
    other distros recently, but they were generally in agreement last time I
    heard. There's not a lot of 'working out' to be done -- we just need
    Linus to take it.

    Btw, no mention of the rbtree shrinkage. I plan to send that Linuswards
    as soon as 2.6.17 is out too, OK? And the mtd tree too but that's just a
    normal maintainer tree so I _expected_ you to omit that.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-04 23:35    [W:0.022 / U:2.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site