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.
There are two conflicting ideals here, and I suppose they are what
makes this such a heated discussion. And therefore I'll point them
out for people who don't notice it so readily.
1) A compile generating different programs using different sets
of interefaces for the same *.c file when you compile under
2.1.106 instead of 2.1.105 is _bad_ (Linus's point)
2) Maintaining the same piece of information in two places, in two
different source files, is prone to bugs and _bad_
Now here is the set of crutches most people bitch about as a result of
this, via an example. What do I do when I wish to add a new routing
flag to provide some new facility in the networking? Or even better,
what if I add a new protocol stack to the kernel, how do I go about
getting the interfaces into the userland compiler's header file
scope? For these cases, do I:
1) Maintain headers locally in my userland tools.
Result: Bad, same piece of information maintained in two places.
or
2) Propagate the interfaces into glibc
Result: Bad, the delay is far too long and most people don't
ever upgrade glibc let alone "often".
(.. add cases here I haven't considered ...)
This is the answer a lot of us are looking for.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu