Categories
operating systems

why microkernels don’t work

You can almost just see it from this diagram of connected boxes.  I want to think of the whole system as a series of connected state machines.  The arrows show how information is moved around the system with the green arrows identifying paths that carry data to and from the memory. When you fill in the details, you start to see that the proposed sheering off of the “fileserver” from the remaining “kernel” does not actually split state as much as it reproduces it. So much of the state of the rump Kernel needs to be available to the FileServer that the proposed modularity disintegrates.”’

The counter argument, in its best form, can be found at QNX.

http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/fsys.html

Categories
Uncategorized

OS design

Working on a “process algebra” post, I had to look up previous posts on microkernels where I wrote this:

Information hiding is only good design when the hidden information is not needed by the software it is hidden from! If you hide information that you need to share you’re just wasting time. A great example of real modularity is the splitting off of the command interpreter (first in CTSS (corrected)) from the kernel. This split is possible because the designers recognized that there is very little information exchange between kernel and interpreter. An example of a fake module is the attempt of most microkernels to split virtual memory paging and storage caching. The most elegant and efficient message passing interface that can be imagined cannot fix the problem that too much information must be shared to make the resulting monstrosity run properly.

swisspic20051210_6305626_0Which applies to process algebras in that the basic “primitive” of process algebra is the communicating process – dumb idea. The one thing I’d take back from the para above is the overuse of exclamation points. I was more enthusiastic in those days. A related point was made here:

The Le Corbusier fallacy is the mistaken belief that the purpose of engineering works is to impress passersby with a show or spectacle or to exhibit the aesthetic sensibility of the artist. In architecture, this fallacy produces high rise slums that look striking from the highway but that are uninhabitable. In programming, the fallacy produces microkernel operating systems, “formal methods”, functional programming languages, and other “simple”, “clean”, “elegant” designs that do nothing interesting. De Botton compares the Salginatobel Bridge in Switzerland to Brunel’s Clifton Suspension Bridge in England and finds the first to be elegant and the second to be clunky and “ponderous”. Of course the Brunel bridge is bulkier than the swiss toy: it is far larger, carries much more and much heavier traffic, has been adaptable, and was built 100 years earlier with much less capable materials. But one might as well argue that clipper ships are ponderous compared to jet-skis, or that 727’s are not as lightweight as paper airplanes or that UNIX systems are more bloated than some academic proof of concept. The Salginotobel bridge is cute and features a bravura use of what was new technology in the 1930s when it was designed, but the Clifton bridge has been an engineering and aesthetic triumph since it was completed in the 1860s and it is a far more powerful work.

[cite]

This post has a perhaps unmerited slap at Corbusier who did design some nice buildings.

What does it have to do with process algebra?