Supporting a GNU Hurd port?

Scott James Remnant scott at
Wed Dec 9 20:06:34 UTC 2009

On Wed, 2009-12-09 at 14:48 -0500, John Moser wrote:

> Linux works, but if we believe (or verify... actually it's been
> verified) that there are any cases where a driver can crash (i.e. disk
> driver, net driver, both have been made buggy to demonstrate) and the
> system can recover, with zero risk of the buggy driver stamping all
> over other parts of the kernel, then we've reached a situation where a
> class of bugs can't actually happen and certain very real bugfixes
> we've seen in the past are now a convenience thing.
That's certainly how things are supposed to work.  A lot of this kind of
robustness comes from the requirement to support SMP systems, and make
the kernel highly pre-emptible on UP systems.  The kernel itself, and
its drivers, basically become a cloud of related threads/processes.

> Personally, I used to not be able to use Ubuntu happily for 2 releases
> because the driver I was using had multiple type mismatches on 64-bit
> architecture (idiots thinking sizeof(int) == sizeof(long)) and
> eventually the video driver decided to stamp all over kernel memory
> and demolish the whole friggin' system.  My eventual solution was to
> move to a different video card by a different manufacturer.  THREE
> related bugs in that driver were fixed, but more remained elusive.
For the last 2 releases?  The video driver has been an entirely separate
userspace process from the kernel entirely, and demonstrates nicely why
microkernels aren't a magic fix for this kind of problem.

The reason your video card driver can crash your hardware is because
your video card hardware can crash other bits of your hardware (which is
most likely what's gone on here).

NVIDIA perchance?

The usual microkernel religious argument is that by having drivers as
separate processes from the kernel, they can't take out the kernel.  The
usual monokernel religious argument is that it doesn't solve anything,
because you still have to communicate between drivers, share resources,
etc. and thus still hit the exact same deadlocks anyway.

If your memory controller is stalled waiting for your video card, which
is stalled waiting for the video card driver, which is stalled waiting
on the memory controller - you're doomed no matter how many different
contexts you broke that down into <g>

Scott James Remnant
scott at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Ubuntu-devel-discuss mailing list