lkml.org 
[lkml]   [1998]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectLKILP (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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.881 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site