Linked by Michael Voigt on Tue 12th Sep 2006 21:07 UTC
OSNews, Generic OSes If you are in Germany, the country of Sauerkraut and Beethoven, and you move far to the east, you might arrive at the town of Dresden. In this city, the Dresden University of Technology (TU Dresden) is located, which's operating systems group has developed a C++ implementation of Jochen Liedtkes well-known L4 -kernel interface. This microkernel, ironically called Fiasco, is the center of all the different projects of the TU Dresden Operating System (TUD:OS) research group.
Order by: Score:
Two things...
by Morin on Tue 12th Sep 2006 23:10 UTC
Morin
Member since:
2005-12-31

which are often forgotten about microkernels...

The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn't have to - in fact, other processes *ask* the disk driver to transfer *their* data. Do these OSes check all data from the disk driver for integrity? And how do they make sure that data is written when the driver says so? I can continue the list of possible problems endlessly here.

Lesson #1: Safety, security, stability and similar features are more than isolating processes against each other.

The second issue is that all processes run in parallel. This mixes up the order of events during processing, very much like IP packets get reordered on their way to a remote computer. The results are nondeterministic, and thus unpredictable. The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.

Lesson #2: If you couple modularity with concurrency, you are begging for problems.

Reply Score: 5

RE: Two things...
by Frenetic on Wed 13th Sep 2006 01:02 UTC in reply to "Two things..."
Frenetic Member since:
2006-05-01

I'm not rooting for or against microkernels, but here are my thoughts on your points:

The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn't have to - in fact, other processes *ask* the disk driver to transfer *their* data.

Everyone should know that a microkernel does not itself ensure that code is trusted, or that code does not need to be trusted, or that flaws in code will have no serious impact. All that is ensured, is that memory and resources will be compartmentalized between drivers. However, some people do seem to (erroneously) imply that microkernels make the kinds of guarantees you described! But of course this aspect of microkernels, while having many benefits, is still a far cry from being a silver bullet.

The second issue is that all processes run in parallel. This mixes up the order of events during processing . . . The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.

Once again, some people can be seen as implying that microkernel systems are dramatically simpler than monolithic systems, which is a misconception. What is mentioned above is indeed one of the major caveats in implementing a microkernel. However, there are solutions to this problem, that keep things relatively simple once implemented. The real problem is that its hard to avoid taking very significant performance penalties when solutions to synchronization issues are implemented. IIRC, the Hurd had this problem, and is trying to curtail such performance penalties by tailoring their system specifically for Intel x86 architectures.

Reply Score: 3

RE[2]: Two things...
by Morin on Wed 13th Sep 2006 10:50 UTC in reply to "RE: Two things..."
Morin Member since:
2005-12-31

Thanks for your reply. I should have said that these problems are not fatal, and they do not make use of a microkernel impossible or even impractical. One just has to be aware of them.

Reply Score: 3

v TUD OS...oops
by Gadget on Tue 12th Sep 2006 23:13 UTC