Tue, 09 May 2006
Why not microkernels?
I teach UNIX at our faculty. When thinking about the general principles of the operating system design, I still find the 1992 debate between prof. A. S. Tannenbaum and Linus Torvalds quite interestng. Today, a new paper by prof. Tannenbaum on this topic has been discussed on SlashDot. I think this comment neatly sums the problem up:
Kernels don't often crash for reasons related to lack of memory protection. It's quite silly to imagine that memory protection is some magic bullet. Kernel programmers rarely make beginner mistakes like buffer overflows.
Kernels crash from race conditions and deadlocks. Microkernels only make these problems worse. The interaction between "simple" microkernel components gets horribly complex. It's truly mind-bending for microkernel designs that are more interesting than a toy OS like Minux.
Kernels also crash from drivers causing the hardware to do Very Bad Things. The USB driver can DMA a mouse packet right over the scheduler code or page tables, and there isn't a damn thing that memory protection can do about it. CRASH, big time. A driver can put a device into some weird state where it locks up the PCI bus. Say bye-bye to all devices on the bus. A driver can cause a "screaming interrupt", which is where an interrupt is left demanding attention and never gets turned off. That eats 100% CPU. If the motherboard provides a way to stop this, great, but then any device sharing the same interrupt will be dead.
I think the problem is often the same with any other academic research versus the real world (sometimes even for research at our faculty - no, I would not be more specific here :-) - usually it is much more simple and nice to create something for research purposes only, and it is much harder, dirtier, and often not better than other (non-"scientific") approaches to apply the results in the real world.
1 replies for this story:
Milan Zamazal wrote:
I don't think there is any special separation of academic research and the real world in comparison with other areas. Problematic design can occur anywhere. Making something cleaner while introducing unwanted complexity elsewhere is a common mistake. And things are worse in business, because business often has the power to actually spread its inventions. BTW, a very typical example of making things clean while making them more difficult is Scheme (trying to "fix" Lisp).