On Thu, 27 Apr 2006, David Woodhouse wrote:
>
> 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.
.. and that's generally the job of library maintainers.
I disagree violently with the notion that any normal system should _ever_
have the regular headers have anything to do with "what kernel source is
installed right now". It is untenable to expect kernel developers to have
to worry about user-level header problems.
> 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.
AND WE SHOULD NOT HAVE TO!
Linkages are bad. We _will_ break kernel headers for user space, and
that's just a undeniable fact.
If this is work to try to make kernel headers generally palatable to user
space, I'm not going to apply it at all. Not now, not early in the 2.6.18
sequence, not EVER. Because that's not a goal I believe in for a moment.
In contrast, if this is work to make it eventually _easier_ for _library_
people to decide to upgrade their kernel-related information, I'm ok with
it. But that "target audience" part really is very very important. The
target audience should NOT be applications including kernel headers.
The target audience should be distributions and library maintainers.
Linus
-
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]