Slashdot Mirror
Get To Know Mach, the Kernel of Mac OS X
An anonymous reader writes "Linux is a kernel, not an operating system. So what is Mac OS X's kernel? The Mach microkernel. The debate around Monolithic (Linux) and Micro (Mach) kernels continues, and there is a great chapter online about the Mach system from the very good book 'Operating System Concepts'. Which design is better? I report, you decide." Warning: link is to a PDF.
The modular design of microkernels makes for easier design & debugging, and with some designs the freedom to make user space services that can only be in privileged space in monolithic designs, but does one want to pay the overhead for all that message passing? Now that we are getting into parallel processing at the consumer level with multicore and hyperthreaded chips, maybe the answer is yes.
So, even though it uses Mach, you can't call it a Microkernel.
Although Darwin does use Mach at the heart, it also has large chunks of the BSD kernel bolted on to avoid Mach's typical performance hit. Consequently, OS X really isn't microkernel, and you can't do all the cool microkernel tricks (load or unload almost anything dynamically, drivers can't crash the OS, etc).
This approach doesn't make much logical sense to me, but it's what Steve and Avie wanted, and somehow, amazingly, it still just plain works.
In this day and age, there is no reason to use a macrokernel unless your hardware lacks the features needed for a microkernel. QNX has proved this quite nicely.
It is based on Mach with a BSD compatibility layer
It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.
Monolithic kernels are dominant in practice (so far). Windows started off microkernel-y but has ended up rather monolithic (at least partly for performance reasons). Xnu (Darwin / MacOS kernel) also has strong monolithic leanings, despite being based on Mach.
The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...
Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.
Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.
Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).
The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
mkLinux is not the only microkernel Linux - L4Linux is still maintained and is much more advanced. Nor are these the only Linux kernels to run in userspace - UML Linux, for example, does just fine. It is not clear where XEN fits into the picture.
All in all, though, the situation with Linux is actually a highly complex one, and should not be regarded as being definitely anything.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Although interesting, Mach was developed at a university and shows a huge number of problems as a result. Notably performance is terrible, due largely to the IPC performance. When people actually tried the "collection of servers" operating system in Mach 3, it was clear it was simply not a workable solution. Workplace OS, Star Trek and any number of other OS's died as a result.
What's sad about this is that the failure of Mach tainted ALL ukernels. By the mid-1990s the idea was basically dead. But what an idea! Don't have your machine on a network? Simply don't run the network program. Using a diskless system? Don't run the disk server. Don't want _VM_... no problem. You can use the exact same OS image to build anything from a minimal OS for a handheld to a full-blown multi-machine cluster, without even compiling. No pluggable kernels, no shared libraries, no stackable file systems, nothing but top and ls.
But it just didn't work. IIRC performance of a Unix app on a truly collection-of-servers Mach was 56% slower than BSD. Unusable. Of course you can compile the entire thing into a single app, the "co-located servers" idea, but then all the advantages of Mach go away, every single one.
Now, given this, the question has to be asked: why anyone would still use it? Don't get me wrong, there are real advantages to Mach, notably for Apple who ship a number of multiprocessor machines. But the same support can be added to monokernals. Likewise Apple's version has support for soft realtime, which has also been added to monokernels. So in the end the Mac runs slower than it could, and I am hard pressed to find an upside.
Of course it didn't have to be this way. The problems in Mach led from the development process, not the concepts within. As L4 shows, it is possible to make a cross-platform IPC system that is not a serious drag on performance. And Sun's Spring went further than anyone, really re-writing the entire OS into something I find really interesting, and still providing fast Unix at the same time. I'd love to see someone build Mac OS X on Spring...
I would disagree with you there. Apple's design may not be beautiful, but it certainly has the best of both worlds.
The BSD Layer, Memeory Managment, etc are all built inside XNU (OS X Kernel) but at the same time its still functions as a microkernel allowing things such as Kernel Extensions (Kext).
The problem with a fully MicroKernel is that its very slow because of all the context switching that has to go on between userland/and kernel land to do what is essentially kernel functionality. Apple solved this by making XNU not act as a microkernel for things such as the BSD layer.
The result is a Kernel that is less prone to panics. In Linux a bad KLM would certainly panic the kernel because it runs in the same address space as the kernel. In OS X a bad Kext would just die like anyother user space program.
As you said, it may be ugly in your opinion, but it gets the job done, it has the best of both worlds, and its less prone to panics. Now that's what I call a step in the right direction.
There is one very easy way to kill a microkernel's performance - force it to use a synchronous system call API (e.g. POSIX). With a synchronous system call API, a context switch is required for every system call. With an asynchronous API, the process simply writes messages into a buffer (or set of buffers for different kernel services) until it either needs to wait for a response or its quantum expires. At this point, you switch to the next context (perhaps a kernel server) and process the incoming messages. This reduces the total number of context switches (and, more importantly the number of mode switches). If you want to see good performance from QNX, then use the native system call API, not the POSIX wrapper.
I am TheRaven on Soylent News
To couch them in terms of Monolithic versus Micro would be like trying to classify an economy as Capitalist or Communist.
Neither economy has ever existed in it's pure form. Both descriptions also have political overtones that have precious little to do with their actualy description.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming