Hypercritical
A kernel of truth: the plot thickens
If Mach is really on its way out, what could replace it?
As usual, I got some great email and comments on my last post about the rumblings surrounding the Mac OS X kernel. Two comments in particular have prompted this quick follow-up. The first was from the ever-inscrutable Rosyna who pointed out a blindingly obvious reason for the still-unreleased x86 kernel source code.
It seems you have missed the most logical reason for Apple not releasing the source to the x86 tree of the kernel. Namely, that it may contain third party source code (for Rosetta support) that they cannot release.
Duh, I had entirely forgotten about Rosetta (a testament to its transparency, maybe?) and the licensed technology it's based on. The need to trim out all the (presumably) closed-source bits licensed from Transitive would certainly put a damper on timely x86 kernel source publication.
Assuming it's possible to release a kernel source tree with all the Rosetta code carefully removed, two questions arise. First, is that a reasonable thing to do? Part of the point of releasing source is so that others can help find and fix bugs, both in the kernel itself and in their own code. But if a Transitive-free kernel is significantly different than what's actually shipping, how much of a help is it to have this source?
Second, assuming the removal of Rosetta doesn't move the source too far from the shipping kernel to be useful, then why hasn't it been removed by now? It's been months since the x86 kernel source was expected. Surely if it's just a matter of making sure all proprietary code is excised, it'd be done by now.
This, in turn, leads into my theory about the Tiger x86 kernel source being an evolutionary dead-end. If it's a pain to remove all the Rosetta code and the shipping x86 kernel bears little or no relation to the Leopard kernel, then the "stall until August" strategy makes perfect sense.
The second comment, from Michel Galle, touched on a topic that I meant to address.
Apple clearly said while the tiger release than there will no change in the kernel api for years to come, to stabilize kernel extensions and drivers. So I cannot fathom a change of kernel, it will totally break “kernel api freeze.”
This topic was alluded to by the link to the kernel section of my Tiger review in the last paragraph of my earlier post. The introduction of a stable, supported kernel API was perhaps the most important core OS change in Tiger. But I don't agree with the conclusion drawn by Michel. In fact, I think the stable kernel API and abstraction layer added in Tiger lends support to the theory that major kernel changes are coming in Leopard. Abstraction is exactly what's needed when you plan to change the underlying implementation.
This, finally, leads to the big question lurking behind the Great Kernel Swap theory. If Mach is being replaced, what will it be replaced with? I haven't bought into the Glamour Choices: FreeBSD and Linux. Although moving to the Linux kernel would probably be a PR coup, it's a politically and legally incompatible—not to mention API-incompatible—choice.
The FreeBSD kernel is the obvious contender. Apple uses a bunch of this code already. But Mac OS X also takes advantage of many of the features that are unique to Mach. Entirely replacing the microkernel-welded-to-a-BSD-kernel monster with a plain old BSD kernel would require some significant re-plumbing and sacrifices.
For the sake of completeness, I will also explicitly pooh-pooh the Crazy Choices. Jonathan Schwartz's pipe-dreams notwithstanding, the OpenSolaris kernel, with its hardcore server/enterprise focus, is just too big of a philosophical mismatch. Never mind that partnering with a potential hardware and software competitor on the core of your flagship software product is not such a hot idea regardless of the technological issues. Speaking of which, forget about “the NT kernel” or “the Vista kernel” or any other theory involving Microsoft in any way. (Save it for the entirely separate “Apple switching to Windows” conspiracy theory where it belongs.) NuKernel, the BeOS kernel, QNX, Newton: no.
So what's left? To find a spiritual and technological successor to Mach, it helps to understand the history. Mach started as a project at Carnegie Mellon University, and had a long life in academia. It spawned many other microkernel projects, including Mach 4 at the University of Utah and several offshoots inspired by Mach that don't share the “Mach” name at all. Many of these projects attempt to address the shortcomings of Old Man Mach.
Historically, the operating system that started as NeXTSTEP and has become Mac OS X today has lagged behind the cutting edge of academic research when it comes to kernel selection. For example, NeXTSTEP stuck with a variant of Mach 2.x long after Mach 3.0 was the latest and greatest. Today, the microkernel portion of the Mac OS X kernel remains a mishmash of many Mach versions, including Mach 3. But even Mach 4 is pretty old news. Whither the new hotness?
A little Googling around the topic of operating system research will bring up some pretty crazy stuff. That's academia for you. What Apple needs is something that's close enough to a traditional microkernel to be feasible replacement for Mach, modern enough to have addressed most of Mach's shortcomings, but old enough to have been proven to some degree in the real world.
As you might have guessed, I have a contender. It's a microkernel that should be familiar to most people who have studied operating systems in the past decade or so. It's called L4. Like LLVM, another semi-obscure infrastructure-type project that Apple has recently taken a shine to, L4 is just the right size and character to be adopted by Apple. It's not too big, like Linux or Solaris or anything else with tons of preexisting developers and legacy baggage, nor is it completely obscure and untested. L4 seems just right.
Of course, it's still not quite a drop-in replacement for Mach, which means that there's still the issue of getting the existing Mac OS X driver model and welded-on BSD kernel to talk to L4 in the same way that they talk to Mach. But hey, would you look at this…
The L4/Darwin project is an experimental port of Darwin to the L4 microkernel to study the characteristics of a large-scale microkernel-based system. It includes a port of IOKit to L4, a modified libc to communicate with the Darbat Server, and of course XNU with many of the machine-dependent parts heavily modified (pmap, thread/task creation, etc) but much left unchanged (most of BSD, and large parts of OSFMK work without modification).
That seems mighty convenient, doesn't it? It's not a slam dunk, but if Mach really is being replaced in the Leopard time frame, L4 looks like the prime contender to me. WWDC can't come soon enough…
This article originally appeared at Ars Technica. It is reproduced here with permission.