Tangent discussion w/Dwarf: Re: Potentially serious problem with kernel-headers...
>The problem actually originates because there is no defined, solid,
>unchanging, interface to the kernel. It is libc's responsibility to offer
>this "consistant" interface to the rest of the system, but libc depends on
>consistancy in kernel headers in order to be capable of providing such.
Fair enough, but libc does not wrap every interface. Even some
interfaces it wraps (eg, ioctl()) are very sensitive to underlying
changes. And thene there's the problem of "who's protecting libc?"
>There is currently a, sometimes heated, debate going on right now between
>the kernel maintainers and the glibc maintainers about just how to deal
>with this.
I realize that I'm about to aim my $.02 at you, Dwarf, but this is
meant to be directed at a larger community (which likely does not
include you). Feel free to deflect it to such.
>Distributions have been "dealing" with this problem for as long as I can
>remember, and Debian's solution seems to lead to a more stable system in
>general, while allowing for "special case" conditions where more specific
>kernel headers are required. The consistancy of the distribution relies on
>the correct choice of kernel headers for the range of kernels and packages
>the distribution intends to support. We provide this by insisting on a
>libc-dev that provides that consistancy. We must, however, rely on the
>kernel to supply "backward" compatibility, and sometimes this just will
>not happen. Those package so effected must depend on, and build with,
>different headers than the rest of the distribution, and must be "watched"
>much more closely than "normal" packages.
A fair assessment of current stste.
>I encourage all maintainers with packages that fall into the catagory of
>"special needs" from the kernel headers, take a close look as the programs
>use of these "features" and see if you can get the same results throught
>"more stable" system calls that do not require the knowledge of kernel
>internals. (This seems to be the position Linus has taken, although I'm
>not sure I completely understand his position...)
This is fine for people writing a spreadsheet or calculator. What
counts as 'special features'? Xterms that beep? What the X server
needs? Any multimedia application (like the ones I write)? Cdparanoia
(which is using long published interfaces to get to the cdrom)? I'll
wager most apps that Linux folks rely on are seeing some fallout from
being declared 'special needs'.
My great fear is this: I can distribute *one* binary that works under
Solaris. One that works under NetBSD. (We won't talk about AIX or
IRIX). Do I need to release a multitude for Linux? "This one works
with 2.0.33, this one with 2.0.34 *unless* you have this patch, in
which case use this one, unless there's SCSI support in which
case...." (cdda2wav, my esteemed competition, already has to do this.
When building it from source, one builds against particular kernel
#define settings. Cdda2wav, once built, will likely work on no other
machine).
Several folks will now say "don't release binaries". What am I to do,
then, on MITnet where the binaries are being served out of network AFS
cells? 2,000 Linux machines, of every imaginable kernel
configuration, are all getting my applications from single binary
images on a server. I'm bloody well going to fight to make sure they
can all run the same one, version of their kernel and libc be damned.
(Libc is already hopeless as about a third are still running 5.3.12, a
third running 5.4.x and the rest glibc 2, and all three are
incompatable. I have to serve a statically linked executable. *All*
the executables have to be static because of this free-for-all.
Shame!!)
If these suspected kernel header changes are a reality, they were in a
*subminor* release. Not 1.0->2.0. Not 2.0->2.1. 2.0.33->2.0.34.
That's *crazy*. How the Hell can anyone keep their system stable
without a full reinstall every month (or never upgrading, which is
already the choice of most Linux users, including *mine*). What are
we trying to be? Microsoft Windows? Hell, here's an example where
Windows is *more* stable than Linux.
>Feel free to coordinate with me, and be sure to communicate with the
>author and get his feelings about the way things could work more kernel
>independent.
>
>Please note as well, I am not one who thinks that future kernel changes
>will not happen, or that they will not effect applications level programs
>when they do happen, but I do think that a lot more can be done to
>insulate apps level code from kernel specific problems.
A few style tips. Very general stuff, but too many developers in the
Linux world seem not to have figured it out. (Again, Dwarf, this is
not directed at you; it's directed at my opposing viewpoint).
1) Think ahead, dammit! Don't unleash the first thing that sort-of
works with just your application on the entire world! Coding is not
the most important aspect of hacking; planning and forethought are.
Code is fleeting; interfaces last forever.
2) Look at what other people have done! Plagarize shamelessly. I can
think of few Linux kernel interfaces that could not have benefitted
from stealing good ideas from elsewhere. If the entire world is doing
something differently, you're either a genius or wrong. Ponder this
deeply before releasing.
3) If you've *not* thought ahead (or you have the misfortune of
cleaning up someone else's mess), either be completely compatible
(forward and backward; old binaries live forever), or make a clean
break. If you make the clean break, make it on a major release
boundary, and make alot of noise when you do it.
Monty
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: