lkml.org 
[lkml]   [2006]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: State of userland headers
Date
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
> patches).

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:

http://www.gentoo.org/cgi-bin/viewcvs.cgi/src/patchsets/gentoo-headers/?root=gentoo

> 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."
> #else
> /* Kernel-only declarations/definitions */
> #endif

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.

Rob
--
Never bet against the cheap plastic solution.
-
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/

\
 
 \ /
  Last update: 2006-03-24 22:27    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site