[lkml]   [2004]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
    Followup to:  <>
    By author: Kyle Moffett <>
    In newsgroup:
    > On Nov 29, 2004, at 15:01, H. Peter Anvin wrote:
    > > Most people seem to have suggested include/linux-abi for this; I would
    > > personally prefer include/linux-abi/arch for the second.
    > It seems like there are two ways to adjust the headers. We could move
    > the private headers to a new directory (include/kernel?), or we could
    > move
    > the public headers to a new directory (include/linux-abi?). I am
    > willing to
    > work on some simple and trivial patches to begin doing either one, if we
    > can reach an agreement as to which one is preferrable (and what to call
    > the new directory.)

    If we can preserve compatibility, moving the private headers to a
    separate place makes sense. However, preserving compatibility is not
    a good thing, because a lot of the brokenness is in how things are
    exported. Thus, you want libc to be able to have a linux/* wrapper
    for backwards compatibility.

    My first choice would be to put the ABI headers in linux/abi.

    > > Good, except your "struct winsize" is bad; you're stepping on
    > > namespace which belongs to userspace. Since we can't use typedefs on
    > > struct tags, I suggest:
    > >
    > > struct __kstruct_winsize {
    > > /* ... */
    > > };
    > >
    > > .. and userspace can do:
    > >
    > > #define __kstruct_winsize winsize
    > My initial suggestion would be to leave the types as-is, primarily for
    > the reasons in Linus' earlier email, but also for simplicity and to
    > prevent inadvertent breakage.

    True; I hadn't considered the weirdness of the namespace pollution
    issue. However, the issue with struct tags remain.

    Note also that not all ABI issues can be well-described in C headers,
    and certainly not the way it currently is. Syscall numbers and ioctl
    APIs are examples there (I do some hideously ugly hacks in klibc to
    try to auto-derive as much of the ABI as possible; this is part of
    making klibc very easy to port to new architectures and keeps
    maintenance in one place.) However, cleaning up the headers is a
    major step forward.

    > >> (3) Remove all #if(n)def __KERNEL__ clauses.
    > >>
    > >> (4) Remove the -D__KERNEL__ from the master kernel Makefile.
    > >
    > > Bad! There is code in the kernel which can compile in userspace for
    > > testing. This is highly valuable and should be kept.
    > I would propose that if we decide to move the public headers instead of
    > the internal kernel headers, we autogenerate headers for installation
    > that have a #warning wrapper if __KERNEL__ isn't defined.

    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: 2005-03-22 14:08    [W:0.033 / U:7.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site