[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__
    On Sun, 2004-11-28 at 17:28 -0800, Linus Torvalds wrote:
    > In particular, any re-organization that breaks _existing_ uses is totally
    > pointless. If you break existing uses, you might as well _not_ re-
    > organize, since if you consider kernel headers to be purely kernel-
    > internal (like they should be, but hey, reality trumps any wishes we might
    > have), then the current organization is perfectly fine.

    Agreed, with the proviso that the inclusion of bitops.h, spinlock.h, and
    other kernel-private stuff like that should not be considered 'existing
    uses'. It's _already_ broken. It won't compile on some architectures,
    and will silently do the wrong thing on others. Causing the compile to
    fail consistently would be a _feature_.

    > So I think this whole discussion has been largely pointless. We undeniably
    > have existing users of kernel headers. That's just a fact. If we break
    > them, it doesn't _matter_ how the kernel headers look, and then "existing
    > practice" is about as good an organization as anything, and breaking
    > things just to break things is not something I'm in the least interested
    > in. "Beauty" comes secondary to "usefulness".

    Usefulness is what we're after. Preventing the naïve user from including
    spinlock.h and thinking that it'll give useful spinlocks would be

    I've lost track of the number of times things have broken because of
    incorrect use of kernel headers from userspace. That's what we're trying
    to fix -- by putting only the bits which are _supposed_ to be visible
    into files which userspace sees, where we know they define part of the
    userspace API and hence we can be extremely careful when editing them.

    I don't think it makes sense at this point for us to bury our collective
    heads in the sand and pretend there isn't a problem here that's worth

    I agree that it should be obviously correct though -- and that's why
    we're trying to end up with a structure that in the first pass would
    give us in userspace essentially what we already have in the various
    glibc-kernheaders packages, but without the constant and unnecessary
    need for some poor sod to keep those up to date by hand.


    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.021 / U:14.964 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site