lkml.org 
[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__
    From
    Date
    On Nov 28, 2004, Linus Torvalds <torvalds@osdl.org> wrote:

    > On the bigger question of what to do with kernel headers in general, let's
    > just make one thing clear: the kernel headers are for the kernel, and big
    > and painful re-organizations that don't help _existing_ user space are not
    > going to happen.

    So, of the following two options, which one you think everybody should
    pick?

    - 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

    - we move the kernel<->userland to a separate package, where it's
    maintained such that it can be used by both kernel and userland, and
    Linux will only build when given a pointer to the location of this
    package.


    I don't think you can have it both ways. As long as the kernel wants
    freedom to set the ABI, either let people use the headers where you
    define it, or maintain the ABI separately and let people use them.
    Forcing others to maintain duplicates of your headers will just get
    most people to use your headers for purposes they weren't meant to be
    used; maintaining two similar but far from identical sets of headers
    in sync is a major pain, that's why few people do it, and even fewer
    people do it properly.

    Refusing to help in the effort to maintain them for wishes of freedom
    to tinker or allergy to external dependencies haven't worked as
    excuses in the past, and I think they never will. Duplicating the
    effort is just stupid, and requiring others to do so is arrogant. Why
    shouldn't we just get together and have something that works for both?

    Or how about we turn the table around and define an ABI that the
    kernel must implement, and then have the kernel have to keep track of
    the changes in such external ABI definition, instead of the way things
    (fail to) work now? How comfortable would you feel with this
    arrangement?


    My usual reply when I hear this argument that the kernel headers that
    define the ABI with userland are to be used by the kernel only, and
    someone else is supposed to create the headers for the same purpose to
    be used by userland, is that you generally won't find the headers that
    expose the interface of a library in a separate package (think
    libz.{a,so} and zlib.h). They're part of the same package, built out
    of the same sources, and there's a reason for that: if they get out of
    sync, it won't serve its purpose. It makes far more sense to maintain
    them together.

    You won't find zlib.h in packages that just want to use zlib, unless
    they contain zlib in its entirety, just in case it's not
    pre-installed. I think this makes perfect sense. Requiring libc or a
    separate package used by libc to contain copies of headers that define
    the API/ABI exported by the kernel to userland is just the same sort
    of nonsense, with the difference that it's a way bigger set of headers
    we're talking about, which renders the problem even worse.

    Sure you can take the easy way out and claim you told people they
    shouldn't do what they're doing when they run into problems because of
    including kernel headers from userland. But as soon as you reject
    proposals to clean things up such that we would have a set of headers
    that both kernel and userland will be able to use, in a way that would
    have the headers still conveniently (for you) sitting in the kernel
    source tree, I can't see that you could say it's not your problem with
    a straight face any more.

    --
    Alexandre Oliva http://www.ic.unicamp.br/~oliva/
    Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
    Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
    -
    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.338 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site