Microkernels, once again
I've once written an article about Microkernels, where I denounce them as being mostly an intellectual fraud.
Someone from the internet (possibly a random student doing homework) sent a mail to me and Jonathan Shapiro asking whether a Kernel was faster than a Microkernel. Here is what I replied.
[Darn, I didn't insist enough on the whole kernel/microkernel issue being irrelevant in the face of the overwhelming issue of the structuration of the higher-level system components. And about the solution being of course no kernel and expressive contracting between components instead. Reminds me of the metaphor of system as society and kernel as government: no one needs a government; everyone needs an expressive market of property rights.]
When you consider a change in a parameter, you must always try to identify what remains the same. Otherwise, your comparison doesn't make sense. Most importantly, be wary to avoid accounting fallacies, whereas some cost has been displaced among software components, or between development-time, compile-time and run-time, yet the displacement is counted as a positive creation in one place without being counted as a negative destruction in the other place.
As for me, the article I wrote considers implementation of a system with same functionality.
Microkernels imply an overall system that is slower, more complex, etc. Compare Darwin vs BSD, MkLinux vs Linux, etc.
The only remotely redeeming quality that I see in Microkernels is that they may help with partitioning trust among various system components. Then again, this feature has been largely overrated, since in practice, a useful and robust system requires the system resulting from the interacting system components to be wholly trusted by the user, anyway (and this includes all the libraries and applications in "user space" as well as the stuff in "kernel space"). It makes no economic sense whatsoever to be fighting against your hardware and software vendors, etc. And if you develop with them, then it makes more sense spending one-time energy fixing potential bugs than spending time each time to work around detected bugs. (If your whole system is hosed because the disk driver is dead, what's the use of having the rest of the system still living thanks to partitioning, but irremediably idle waiting for a disk resurrection what can't and won't happen? If you build a wrapper to automatically work around some instability in a subcomponent, why not just fix the component?) In a proprietary software settings, it might make sense because you're not able to see inside vendor software and fix it. But then again, microkernels bring little help to the overall system. Concerns of high-level APIs, testing practices, etc., dwarf any concern of micro vs monolithic kernel.
I guess that if you're paranoid, and think that trust is most important, yet you won't trust a system compiler for a high-level language like Modula-3 while you will trust the compiler for a low-level language like C (and will trust the zillion-transistor hardware), then a microkernel might make sense.
As for efficiency, the runtime overhead of a microkernel and development-time overhead of early low-level fixation might well overwhelm any speed advantage in using a low-level language as compared to a high-level language. As for trust, the complexity (= enemy of trust) of a really optimizing compiler for your low-level language might also overwhelm the complexity of a compiler for your high-level language.
Then again, I'm sure that shapj can give you a much more knowledgeable idea of the practical tradeoffs he faced when choosing a microkernel. But I'm sure the paranoid aspect of his project was decisive in his choice. Also be wary that in practice, you seldom get to choose all the components; some already exist and despite intrinsic braindeadness in design, have been subject to so much development that you can trust them reasonably and it makes no economic sense to redevelop a well-designed replacement component from scratch.
As for me, the right paradigm is in the choice of a proper high-level language. And talking about trust-intensive systems, what becomes of the E language? Do EROS people use it to actually build applications? Hum, I'll have to take a look.