On Wed, 2006-04-26 at 19:18 -0700, Linus Torvalds wrote:
> Hmm. Every time we've done this in the past, something has broken, so I'd
> actually _much_ rather wait until early in the 2.6.18 cycle than do it
> now.
OK. I've tried to be _very_ conservative with this set -- it mostly is
just a case of moving #includes from one part of a header file to
another so they aren't exposed to userspace. I figured the more
interesting stuff could come later.
But if you'd rather have it only in -mm only for now, that's fine.
> Yeah, people shouldn't include kernel headers, but if they didn't, this
> patch wouldn't matter. And when they do, patches like this tends to show
> some strange app that depends on the current header layout.. Gaah.
Well, yes, but we all know that people _have_ to include kernel headers.
We can't just bury our head in the sand and say "they mustn't do that".
The kernel headers contain all the juicy stuff like structure
definitions and ioctls which you _need_ in order to communicate with the
kernel.
The problem is that we don't actually have any _discipline_ about how we
throw our kernel headers over the wall. We never even _think_ about how
usable they are in userspace, or how what we're doing will affect
userspace.
That's why there are so many silly little cleanups which I had to make
just to be able to use some recent kernel headers sanely again in
userspace, instead of the ancient fork we'd taken in Fedora from a 2.4
kernel.
The answer to this lies in my other git tree, at
git://git.infradead.org/hdrinstall-2.6.git -- again in gitweb, at
http://git.infradead.org/?p=hdrinstall-2.6.git;a=summary
Based on an original implementation by Arnd Bergmann, this implements
new 'make headers_install' target for the kernel Makefiles, which
exports a selection of the contents of our include/ directories to
userspace, having run them through unifdef where appropriate.
This gives us a pristine set of headers which _are_ suitable for
userspace inclusion. I've been talking to maintainers of the
'kernel-headers' or similar packages in other distributions, and we seem
to have a consensus that this is going to be useful. All the
distributions can ship basically the _same_ set of headers, instead of
all doing their own thing to clean them up, and getting it inconsistent
across distros.
As well as achieving that laudable goal, the export step also allows us
(and in particular our janitor-types) to _read_ through the headers
which userspace gets, and start to clean them up a bit more, cleaning up
namespace pollution and removing things which are still visible but
which shouldn't be. It allows us to take a diff of the _exported_
headers between one release and the next, and see the user-visible
changes in isolation.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
