Sigh. I guess he’ll just never get it. Linus is off railing against microkernels again, even though it seems he has never worked on what he’s criticizing and isn’t aware of current reality. Mach (specifically as it came from CMU and not in later forms) is a convenient whipping boy for every OS programmer who’s afraid of change, but it’s not at all representative of what microkernels today can do and have been doing for ages. Here’s the part where Linus goes most completely off into the weeds.

The fundamental result of access space separation is that
you can’t share data structures. That means that you can’t
share locking, it means that you must copy any shared data,
and that in turn means that you have a much harder time
handling coherency. All your algorithms basically end up
being distributed algorithms.

And anybody who tells you that distributed algorithms
are “simpler” is just so full of sh*t that it’s not even

Where to begin? Let’s start with his claim about copying data. What needs to be copied is information, not data, and the information needed to satisfy a single request is often much less than the whole set of data related to that request. For example, if you want to read a file remotely, you don’t need to pass your entire file data structure. You can pass a handle which maps easily to a corresponding structure at the other end (plus offset and length and so on). The amount of actual data copying that needs to be done in a microkernel or distributed system is much less than Linus seems to think.

Secondly, sharing data structures and locking is often something you shouldn’t be doing anyway. Besides the obvious implication for correctness when you have more code sharing the same data structures, there can actually be performance implications. More code locking the same data structures means more contention for those locks. Linus quite correctly points out that the performance issues in microkernels is less about implementation details than about the algorithms that they impose on you, which is really just an example of the old “optimize algorithms, not code” from your first computer-science class and applies to monolithic kernels as well, but somehow he doesn’t apply that lesson to locking. One of the classic ways to deal with excess lock contention is to reduce sharing by bringing some data “out from under” the lock, which is exactly the same thing that microkernels force you to do.

Lastly, as regards distributed algorithms, even Linus has observed (elsewhere) that the world is moving more and more toward networks and clusters instead of separate standalone systems. Nobody’s claiming that distributed algorithms are simpler, but they’re unavoidable. They’re part of what every programmer has to know to be effective in the modern programming world, and an operating system which is already designed as separate components is very much easier to make distributed. If Linus wants to worry about memory copying, he should think about how Linux limits process migration to a coarse-grained and heavyweight checkpoint model.

Anybody who has ever done distributed programming should
know by now that when one node goes down, often the rest
comes down too. It’s not always true (but neither is it
always true that a crash in a kernel driver would bring
the whole system down for a monolithic kernel), but it’s
true enough if there is any kind of mutual dependencies,
and coherency issues.

Now Linus is getting bogged down in exactly those implementation issues he said we should avoid. Anybody who has ever become good at distributed programming should know by now that with competent design and implementation the frequency with which one node takes down others can be very low. It becomes very much the exception, not the rule; with monolithic kernels the phenomenon of one component bringing everything down remains the rule, not the exception. Just because the fault-propagation rates in question are neither 0% nor 100% does not mean they’re equal, so Linus’s attempt to paint the problem the same way for distributed systems and monolithic kernels is specious.

Projects such as L4Linux or QNX have already shown that one can gain (at least some of) the robustness and/or distribution benefits of microkernels with minimal impact on performance. That’s manifest reality. For Linus to continue repeating claims that conflict with reality says far more about him and his “leadership” than about reality.