State of userland headers
rob at landley.net
Fri Mar 24 22:23:49 CET 2006
On Friday 24 March 2006 1:51 pm, Kyle Moffett wrote:
> On Mar 23, 2006, at 12:11:26, Mariusz Mazur wrote:
> > There was a thread on lkml on this topic about a year ago. IIRC
> > I've suggested, that the best option would be to get a new set of
> > dirs somewhere inside the kernel, and gradually export the userland
> > usable stuff from the kernel headers, so to (a) achieve full
> > separation and (b) avoid duplication of definitions (meaning that
> > kernel headers would simply include the userland ones where
> > required). Linus said, that it would break stuff and so is
> > unacceptable.
> I seem to remember Linus saying that "breaking things is
> unacceptable", not that the project was guaranteed to break things
> (we would just need to be much more careful about it than most kernel
The gentoo guys clean up their own headers, apparently. I'm told they do so
by moving around the #ifdef __KERNEL__ stuff to be in the correct places, and
that they're currently working on a 2.6.14 or 2.6.15 version of the headers:
> What that seems to indicate to me is that an in-kernel
> version would need to do the following for userspace-accessible
> header files for a large number of kernel releases:
> #ifndef _LINUX_HEADER_H
> #define _LINUX_HEADER_H
> #include <kabi/header.h>
> /* Define or typedef a bunch of __kabi_ prefixes to the old
> prefixes they used to have in the kernel header */
> #ifndef __KERNEL__
> # warning "The header file <linux/header.h> is deprecated for"
> # warning "userspace, please use <kabi/header.h> instead."
> /* Kernel-only declarations/definitions */
Changing the #include paths in all deployed software will basically never
happen. If this header package requires that, I'm not interested in it
because I can't build existing software against it, and I don't expect anyone
else to be.
I was thinking of possibly a parallel header set under linux-2.6.x/usr/include
which the linux-2.6.x/include/*.h could #include to clean out their #ifndef
__KERNEL__ stuff, and that eventually the usr/include stuff would contain
approximately what Mazur's headers had contained. Unfortunately, I'm under
the impression that's not a realistic approach.
> If this were done carefully, all programs that compile against kernel
> headers could be _fixed_ in the short term (they'd go from throwing
> errors to giving a couple deprecation warnings). In the long term,
> the extra ifdeffery could be removed and the <linux/*.h> headers for
> which a <kabi/*.h> replacement had existed for a couple versions
> could be removed. New ABIs (including IOCTLs, new syscalls, etc)
> could be required to use <kabi/*.h> in the first place.
A program that includes kabi/* instead of linux/* won't build against older C
libraries with older headers from older kernel versions (or older project's
like Mazur's headers).
> 1: Ewww, bad glibc!
> 2: The symbols in kabi/*.h should probably all start with __kabi_
Any grand new incompatible thing is something I will happily ignore for as
long as I am able to, and I'm not alone here. Your uptake will be zero.
Never bet against the cheap plastic solution.
More information about the llh-discuss