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

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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-24 22:27    [W:0.023 / U:9.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site