Messages in this thread | | | Date | Tue, 16 Jun 1998 01:43:34 -0700 | From | "David S. Miller" <> | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
Date: Tue, 16 Jun 1998 01:33:37 -0700 (PDT) From: Linus Torvalds <torvalds@transmeta.com>
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
| |