> "Jon M. Taylor" <taylorj@ecs.csus.edu> said:
> > On Mon, 17 Aug 1998, Horst von Brand wrote:
> > > "Albert D. Cahalan" <acahalan@cs.uml.edu> said:
>
> > > [...]
>
> > > > Speaking for myself, I'd much rather upgrade the kernel.
> > > > XFree86 comes with a collection of libraries, and a library
> > > > upgrade often breaks stuff. The kernel is easy to change.
>
> > > Because it doesn't depend on the year's crop on video cards. Put that stuff
> > > into the kernel, it will be _much_ worse than upgrading a library.
>
> > Why? With modules, you can swap stuff around as much as you need.
> > You just need root privs to do it.
>
> Just that an errant libXwhatever can't screw up your disks, a broken module
> certainly can; you are running a _much_ higher risk with modules.
It won't screw up your disks unless it locks the hardware or
chain-oopses the kernel. The first is just as present (and maybe moreso)
in userspace code than in the kernel, and the second can be worked around
by having a simple textmode driver that is always in the kernel (it would
be quite small) and if the console's video driver oopses it can be
deactivated and the consoles mapped back to the fallback mini-driver.
> Besides,
> libs reside in userpsace and can be swapped out, modules reside in RAM.
If they are in use, they shouldn't be swapped out. If they are
not in use, kmod can remove them.
> And finally, being in the kernel doesn't guarantee that version 4.1 will be
> compatible with 3.5 either.
The beauty of the LibGGI-KGI system is that this doesn't matter
too much. The "standard" is the LibGGI API. If the KGI interface
changes, you just update the LibGGI driver libs that talk to KGI and you
are all done.
> The reason the kernel _looks_ stable as an
> interface to outsiders is that the interface from kernel to userland is
> negotiated by libc and system programs.
Same thing as above, but potentially much more of a PITA because
the system programs don't use libc to talk to the kernel, but they DO use
libc in the same way all C programs do. This means that libc is in a
unique situation. If libc itself ran on top of a low-level "LibLinux"
(|->) that could be swapped out as the kernel interface changed, libc
would be shorn of the kernel-to-userspace responsibilities that it has
been saddled with and be able to get back to the job of being the standard
C function library.
> Just look at the Changes file in
> your nearest kernel source, and ask yourself why you have to run those
> library and program versions... the flamewars about kernel interface
> changes have been memorable.
That is because of this dependency web libc generates - see above.
It causes problems. It restricts the ability of the kernel to change its
interfaces to userspace, because everyone will have to update their libcs
and possibly break other software on their system (or their whole system -
when I tried to move to glibc I hosed everything and I haven't tried
since). IMHO, that shouldn't have to happen.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html