lkml.org 
[lkml]   [2004]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
    From
    David Howells wrote :
    > We've been discussing splitting the kernel headers into userspace API headers
    > and kernel internal headers and deprecating the __KERNEL__ macro.

    Linus Torvalds wrote :
    > On Mon, 29 Nov 2004, Alexandre Oliva wrote:
    > >
    > > - Linux gets to define the ABI between kernel and userland, and
    > > userland must duplicate the contents of headers in which the kernel
    > > defines the kernel<->userland ABI, tracking changes in them in the
    > > hope that nothing falls through the cracks
    >
    > This is unquestionably true. The kernel obviously _does_ define the ABI,
    > and userland just lives with it. At some point you have to track things,
    > just because new features etc just can't be sanely handled any other way.
    >
    > That said, I think we can make the tracking _easier_.

    Nice discussion, but nobody is discussing my main concern,
    even if Linus come close to it.
    On my box, I do have multiple kernels. Some 2.4.X, some 2.6.X,
    I may even find some 2.2.X on some of my boxes. Depending on what I
    do, and the bug reports send to me, I boot one of these kernel or
    another. Because Linus is so productive, I update my kernel
    frequently, without changing the user space. I know that some
    distributions are also offering various kernel versions, and let the
    user choose.
    So, which kernel ABI should be present on my system in
    /usr/include/linux and /usr/include/asm ? Should I use the ABI from
    2.6.X, 2.4.X or 2.2.X ? Should I take the time to create a sanitised
    version of the kernel header every time I install a new kernel, even
    though I may revert back to the previous kernel ? Should I recompile
    applications using kernel headers at each kernel upgrade ?
    Currently, it doesn't matter, as so few applications are using
    those headers, and most changes are highly backward compatible. And
    the application that are deeply intimate with the kernel probably do
    run-time tracking of features already, so don't really need those
    headers...

    However, I believe we need to at least ask this question, even
    if I don't think we will come up with a good answer...

    Have fun...

    Jean
    -
    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: 2005-03-22 14:08    [W:2.223 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site