Messages in this thread | | | Date | Tue, 16 Jun 1998 01:33:37 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
On Tue, 16 Jun 1998, Richard Gooch wrote: > > Ted made a suggestion that was leading in a similar direction to what > I was thinking. The basic problem stems from future libc stealing > namespace (types/definitions/macros) that current kernels define, > right?
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
| |