Re: header cleanup and install

[David Woodhouse <dwmw2@infradead.org>]

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
file.

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.

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/