Lessons Learned From 30 Years of MINIX
Andrew S. Tanenbaum (via Jeremy W. Sherman):
My idea was to write the system, called MIni-uNIX, or MINIX, for the new IBM PC, which was cheap enough (starting at $1,565) a student could own one. Because early PCs did not have a hard disk, I designed MINIX to be V7 compatible yet run on an IBM PC with 256kB RAM and a single 360kB 5¼-inch floppy disk—a far smaller configuration than the PDP-11 V7 ran on. Although the system was supposed to run on this configuration (and did), I realized from the start that to actually compile and build the whole system on a PC, I would need a larger system, namely one with the maximum possible RAM (640kB) and two 360kB 5¼-inch floppy disks.
[…]
The L4 microkernel runs on the radio chip inside more than one billion cellphones worldwide and also on the security processor inside recent iOS devices like the iPhone 6. L4 is so small, a version of it consisting of approximately 9,000 lines of C was formally proven correct against its specification, something unthinkable for multimillion-line monolithic systems. Nevertheless, microkernels remain controversial for historical reasons and to some extent due to somewhat lower performance.
[…]
Although funding has now ended, the MINIX project is not ending. It is instead transitioning to an open source project, like so many others. Various improvements are in progress now, including some very interesting ones (such as being able to update nearly all of the operating system drivers, file system, memory manager, and process manager) on the fly to major new versions (potentially with different data structures) while the system is running. These updates require no down time and have no effect on running processes, except for the system freezing very briefly before continuing. The structure of the system as a collection of servers makes live update much simpler than in traditional designs, since it is possible to do a live update on, say, the memory manager, without affecting the other (isolated) components because they are in different address spaces
Wikipedia has more information about L4:
After some experience using L3, Liedtke came to the conclusion that several other Mach concepts were also misplaced. By simplifying the microkernel concepts even further he developed the first L4 kernel which was primarily designed with high performance in mind. In order to wring out every bit of performance the entire kernel was written in assembly language, and its IPC was 20 times faster than Mach’s.
3 Comments RSS · Twitter
While being a lot faster than Mach, it is also a lot less capable.
This is good for simple embedded system that don't need all the things Mach provides out of the box, but to write a real desktop OS on top of it, you will have to rewrite most of Mach's features that are missing from L4.
The reality is that with macro benchmarks (instead or micro benchmarks of the IPC), the increase in performance is far less impressive.
One of the main benefit would be that you can probably achieve the same performance with a true L4 micro kernel than with a hybrid Mach kernel (like XNU).
"This is good for simple embedded system that don't need all the things Mach provides out of the box, but to write a real desktop OS on top of it, you will have to rewrite most of Mach's features that are missing from L4."
Uh, you do realize that being "a lot less capable" is not an accidental bug but THE entire damn feature? The whole point of a microkernel-based architecture is not to bog up the most critical core OS process and code with a ton of userland crud. Otherwise it's not a microkernel any more; just one more monolithic kernel of $size like Mach and Linux and the rest of the clown school.
The goal of MINIX-style architectures isn't to be fast, it's to be safe. As in, utterly, utterly bombproof, from both a security and a reliability point of view. Everything that possibly can go into isolated single-role servers running as non-root processes does. Which nowadays is infinitely more important than pulling a few extra cycles out of a CPU/FPU/GPU combo that already has more or them spilling out its ears than it knows how to use.
Such casual contempt to absolute performance no matter what cost may honk off the retrograde OCD nerds who've nothing better to do with their lives than conduct endless "my CPU is bigger than yours" dick-swinging contests amongst themselves, but who cares what they think? They are a miniscule fraction of a fraction of a fraction of computer users nowadays, and the absolute last people qualified to dictate how technology should work for the other 99.99999% (as the last couple decades have so robustly demonstrated time and time again).
What the other billions who've better things to do absolutely care about is having devices that Just Work, don't fall on their segfaulted asses every time they gets a boo-boo, and don't bend their owners over the barrel on behalf of whatever Russian mobster or NSA spook this week's exciting new security holes have invited in. 'Cos there's nothing "performant" about wading through that crap in your life, week after week after week til forever.
"just one more monolithic kernel of $size like Mach and Linux"
I don't think you know what Mach is. Mach is a real micro kernel that provide nothing more than scheduling, memory management, and IPC.
XNU is a hybrid kernel that is build by merging the Mach layer into a FreeBSD kernel and is definitively not a micro kernel.
The goal of L4 is not to be safer than Mach (that is the previous generation of micro kernel), but to be faster. It do that by removing a lot of the IPC features of Mach that where not useful anywhere and slow down the system.
