Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[David Woodhouse]

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

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

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.

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/