I am familiar with QNX, a beautiful micro-kernel system, my comments
are based on that.
On Mon, 12 Jun 2000, James Sutherland wrote:
> On Sun, 11 Jun 2000, Pavel Machek wrote:
> > Hi!
> >
> > > > 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. 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.
> >
> > Nice things about VSTa ukernel was that things were simple. Do you
> > want to change your keymap? Just recompile keyboard driver, then
> > killall keyboard; ./ikeyboard &
> > ... and keymap is changed. Did your vfat driver crash? Never minds,
> > you just loosed some of your fs's. Just reload the vfat driver.
>
> And, of course, that would work, because the vfat driver (being perfectly
> written) doesn't trash the disks in question when it crashes, right? And
> the crashing keyboard driver leaves the keyboard controller in a known
> state? Sometimes you can recover (reset the keyboard controller, etc.) -
> other times, you can't. What if the video driver caused the video card to
> lock up the PCI bus?
>
That would be broken HW that is being fixed in SW already.
The basic concept is sound, it is just the little implementation
gotchas related to broken HW that make things more difficult.
> Any software which parties directly with the hardware (and, in the end,
> some software must do) can hose the machine. In theory, you can block out
> some possible routes for this happening - but by no means all; in
> practice, I don't think it's actually worth it.
>
If the hardware is properly designed (such hardware exists), it is
not such a big problem.
> With modular drivers, the first example you give works anyway: just "rmmod
> keyboard; insmod keyboard" (assuming that driver is modular, of course;
> making it modular is a lot easier than making it a userspace driver,
> though!). The second you give doesn't work anyway: as a filing system
> dies, it probably takes out the VFS layer. Without that, you no longer
> have access to the on-disk copy of the process you want to reload - so
> you're stuffed anyway.
>
You are probably correct here, but if the OS is mostly in ROM it isn't
a problem.
> > It should not crash, anyway, but hey: we have one userspace driver
> > already. It is called X. Keeping it userspace _has_ stability
> > advantage.
>
> Interesting example - except I've never seen X fail without taking the
> machine with it anyway. In theory, if X fails, I should be able to kill it
> off and access another VT to restart it; in practice, I can't do anything,
> since X also controls the keyboard and mouse. Perhaps I could telnet in
> and try to kill it, then try to find some way of resetting the keyboard
> and mouse remotely over telnet - but rebooting is a lot easier...
>
On this point I must disagree. I have rarely had any failure under X
take down other network services or background processes. Those times
it has have been kernel driver failures that just coincidentally hit X.
Daniel Taylor Embedded and custom Linux integration.
dante@plethora.net (612)747-1609
-
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:25 EST