> "Jon M. Taylor" <taylorj@ecs.csus.edu> said:
> > On Tue, 18 Aug 1998, Horst von Brand wrote:
>
> [...]
>
> > > 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.
>
> No, it just needs a wild pointer and some (bad) luck to trample all over
> the structures VFS keeps in memory.
This could happen, yes. But it could happen with other kernel
code too.
> > > 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.
>
> Exactly! An if you want to change the kernel, and have userpsace see the
> changes, you have to change libc. And you also want to change libc to make
> it more standard conformant/less buggy. And as everybody depends on that,
> you _have_ to change stuff. Tough, no way around it.
Well, actually there is a way around it. You put an abstraction
layer between the kernel and the bulk of libc, which can be swapped out as
the kernel interface changes. Your libc might be a bit less efficient due
to the necessity of talking to the kernel through that abstraction layer,
but it would still *work*. You'd need ELF libs to be able to do this of
course.
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