Namespace is part of it, but organization is even more so.
Different library versions want different #defines and type defines in
different places. Some libraries want to define their own FD_SET, while
older ones want to get the kernel ones. Some libraries want to have xxx
defined in xxx.h, while others want it in yyy.h.
It's a mess. When I make small changes to certain header files, I don't
know what will break in completely unrelated user-level header files.
> An extreme solution would be to have all types/macros/whatever in
> kernel include files prefixed by "Kernel"/"KERNEL_" or something
> similar. We in effect claim a namespace for eternity.
We do that for certain things. The most basic types have a __kernel_xxx
name, exactly to allow certain very limited interaction. But it doesn't
work for everything.
And one point is really that yes, I can see how you can make it work. You
can create separate "exported" subtrees of the header files, and create a
committee to discuss the standards that ensue, etc etc ad nauseam.
But the point is that I DO NOT WANT TO. It is too stifling. I'm more than
happy to maintain binary compatibility backwards (within reason - even
that is occasionally broken, especially for "system binaries" like
"ifconfig" etc). But I refuse to maintain that on a source level, because
I see absolutely _no_ positive feedback from it.
For example, what is the advantage for ext2fs-tools to try to use the
kernel header files?
The tools cannot handle new filesystem types anyway, so "new structures"
and "new constants" does not cut it as an argument. Trying to use the
kernel header files only makes it harder to have cross-compiling etc.
In contrast, having a private copy of what the "struct ext2_inode" looks
like means that you never have to worry. Not now, not in the future. Not
when you cross-compile from Solaris, not when you build natively. Not when
you build with an older kernel that doesn't have the new structures that
you want ext2fs-tools to be able to handle.
Using the kernel header files is horrible. Imagine somebody at some random
Linux distribution company, and some developer tracking new kernel
releases. He does all his development on a new kernel, because he wants to
personally use new features even if the distribution doesn't actually ship
with that kernel by default. He does all the debugging, and creates the
RPM for various packages.
And then they are all compiled for the CD on another machine which happens
to have a different kernel tree. Does anybody _really_ think that it is
acceptable that now suddenly the binaries are different from the ones that
the developer was testing and debugging? Quite frankly, if anybody thinks
that this is acceptable behaviour, I can only pity them.
In short, the build process _has_ to be completely separated from the
kernel, if only to make it completely repeatable. When you install a
compiler and a library, the binaries produced by that compiler and that
library had better be the same regardless of whether the user has updated
their kernel. Anything else is simply not sane behaviour.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu