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?
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.
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.
> 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...
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:25 EST