Re: linux and micro kernel

From: James Sutherland (jas88@cam.ac.uk)
Date: Fri Jun 09 2000 - 09:10:26 EST


On 9 Jun 2000 yoann@mandrakesoft.com wrote:
> James Sutherland <jas88@cam.ac.uk> writes:
>
> > In theory, this is a good thing; in practice, it doesn't gain you very
> > much. If my network server's NIC driver collapses, and it's running in
> > usermode, then the server could continue serving files - except... it
> > doesn't have anywhere to send them! It's effectively dead anyway.
>
> humm, you're talking about a configuration where there is > 1 machine,
> and where each machine is a server ( for exemple disk server, sound
> server )...
>
> What about the same problem if there is only one machine :
> You have no NIC anymore, but the system stand up.

The absence of network access from my machine isn't quite as serious as a
kernel failure, in that I would usually be able to save any unsaved
documents in the former case (assuming I was running the software
locally). If I'm running software over the network, with a local swap
device, I'm stuffed without network access. In fact, the loss of anything
other than perhaps the sound card means the machine dies anyway.

> > Similarly storage drivers, I/O drivers, etc. OK, there are a few
> > "expendable" drivers, where I can continue without them - sound, video,
> > mouse, perhaps. However, if this is a desktop/workstation, I need to
> > reboot anyway;
>
> why ?
> just restart the faulty server, you do not need to reboot the machine.

If that's possible. How do you reload a failed hard drive driver, for
example? A driver may collapse due to internal bugs, but normally the
cause is duff hardware; only a hardware reset will clear that. (Sometimes
not even that.)

> > if it's a server, what does it have a sound card or mouse
> > for in the first place?!
>
> misunderstanding : here, when i'm talking about server, i am talking
> about one entity on the machine which is the ressponssible for such
> or such system task ( eg : sound driver )

I'm using the usual meaning, and using "driver" to mean driver.

> > > The advantage is that there is really not many chance for the kernel
> > > to crash, as it only do minimal thing.
> >
> > It's a nice theory, but in practice you need the device drivers working
> > anyway.
>
> It depend on which driver...

Not many of them are expendable. If I'm running a program over the
network, the loss of my NIC, video card, I/O or storage systems mean I'm
SOL. I don't really gain much in practice from a microkernel approach.

> > Having "the kernel" working, but the machine being isolated from
> > the outside world with no network or disk access, isn't much different
> > from the kernel being dead as well.
>
> Humm, i prefer having a network card down, because of a bug in the
> userspace NIC driver server which i just need to restart...

Assuming, of course, you CAN restart the NIC driver. It could have caused
a PCI bus lockup, in which case you are SOL anyway.

> > > If a driver crash, it doesn't disturb the kernel.
> >
> > No - but it does cripple the machine as a whole, so it might as well take
> > the kernel with it.
>
> well, why ?

Why not? :-) If the loss of the driver disables the machine anyway, I'd
rather panic the kernel (causing a reboot, if that's how I want panics
handled), which will bring the machine back up in a known state.

Microkernels are one of those ideas which sound very good, but don't
really work in practice: there's a performance hit from all the ring
transitions, and you still gain little or no stability. since the loss of
most drivers is "fatal" anyway.

James.

-
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.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:18 EST