Messages in this thread | | | Date | 21 Jun 1998 15:28:00 +0200 | From | (Kai Henningsen) | Subject | LKILP (was: Re: OFFTOPIC: e2fsprogs and +2Gb partitions) |
| |
Richard.Gooch@atnf.CSIRO.AU (Richard Gooch) wrote on 19.06.98 in <199806190821.SAA08242@vindaloo.atnf.CSIRO.AU>:
> Mark H. Wood writes: > > On Tue, 16 Jun 1998, Linus Torvalds wrote: > > [much, including] > > > And why is duplication bad? That's just some semi-religious mantra, but > > > it has absolutely no meaning. Instead of calling it duplication, think > > > of it as "replication", which for some strange reason is considered a > > > positive thing in CS, even though it means the same thing as > > > "duplication" which has these silly negative connotations. > > > > "Duplication" tends to be read as "we have multiple copies of the > > information and they are maintained in parallel by hand". "Replication" > > tends to be read as "we have multiple copies of the information and some > > automatic mechanism keeps them consistent within a few > > {seconds|minutes|hours}". Given what I know about my own ability to keep > > things consistent manually, I much prefer replication to duplication. > > Does that help? > > Nicely put!
So then ...
How about mounting a "Linux kernel interface library project"?
I envision something like this:
* Have a set of linux/* include files.
* In there, expose everything about the kernel that a user space program might possibly want to use. (Help from this list would be needed in determining what that is.)
* Use a restricted name space for _everything_ in there.
* In case there is a conflict between different kernels, have separate definitions *that can be used together* with versioned names, so a program can be built that decides at runtime which to use depending on the current kernel.
* Promise to never, ever, change the definition of any symbols in there. If changes are necessary, use new names. It is more important names stay stable than they are a good description; comments can be used for the latter.
* Try to (eventually) cover every kernel version on ftp.kernel.org.
* Try to include new features *fast*. (Have a mail address where someone can be contacted about needed support.)
* Have a really small library (called libinux.a, so we can "-linux" - a shared library won't make sense) containing stuff like direct system calls and - important - a function to determine the current kernel version that preferrably works on _every_ kernel version.
The result would be that everybody who needs to access stuff in the kernel not covered by some standard include or function, would have a stable interface for that, that's independent of the actual kernel version, and that can be expected to be reasonably up-to-date, not least because it would be independent of libc.
(Actually, libc _could_ probably be built upon it.)
The backwards support feature (combined with the namespace guarantees) means that it would actually be usable for stuff needing to support older kernels/libraries, they would just have to require a reasonably recent version of it. It ought to be designed in a way not to conflict with any existing namespace out there.
The priority would be in covering what people actually need.
It should be a separate package from the kernel - people should not be tempted to use older versions because they use older kernels, as *everything* in the older library should still be in the newer library.
Comments?
MfG Kai
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |