MkLinux: Apple-Funded Port of Linux to the Power Mac / Mach Microkernel

Regular Linux distributions would have to rewrite the kernel, hope it's accepted upstream, fork or patch-and-pray.

I'm sure certain concepts were borrowed from Mach and implemented in Linux and the other way around.

https://en.wikipedia.org/wiki/Mach_(kernel)#Mach_concepts

> And if it adds so much value,

It isn't that simple. There are tradeoffs made with every kernel design decision.

People often tend to stick with what they know.

In the late 80s, the Open Software Foundation (OSF) was founded as a consortium of seven major tech companies spearheaded by DEC to standardize Unix in response to AT&T and Sun's adoption of SVR4. They adopted Mach as part of this and ended up extending it to add locksets, semaphores and resource ledgers. MkLinux was then a joint effort in 1996 by Apple and the OSF to both have Linux on the PPC and exploit Mach features in the single-server emulation.

As such, the history is convoluted. It's not that Mach is so great, but rather that circumstances made it creep in various places.

I went to Sun and learned how a kernel could work and could perform and the allure of Mach, for me, started to wane. Reading the mach code made it worse, especially compared to the Sun code.

All these years later, I remain underwhelmed. Linux has a nicer VM system, performs better, and is more readable. Not Sun level readable by any stretch, but better than my memory of mach (which, to be fair, is in the distant past).

If someone can point to actual real world data that shows Mach to be better performing on the same hardware I'd be interested in seeing that, I tend to think that's not possible.

If you want to see what a real microkernel done right looks like, go look at QNX before they added the POSIX conformance. You have 4-5 people logged into an 80286 doing work. Very, very light weight and well done. They were the only guys that understood what the "micro" in microkernel meant. I remember Dan Hildebrandt telling me that the microkernel easily fit in a 4K instruction cache (it pretty much had to, it didn't do much so you needed some space for whatever it was dispatching).

For example, Apple no longer relies on the Mach port mechanism for IPC, instead mostly relying on their own, better XPC, which forms the foundation for libdispatch (aka Grand Central) and OS X's sandboxing.

Of course, XNU is also a monolithic kernel, not a microkernel.

Transitioning to a different kernel would probably be a costly mostly-zero-velocity project for Apple, especially now that they are no longer in the server OS space. A different kernel might require replacing IOKit, unless one could write a compatibility layer for it.

When Apple bought NeXT, Tevanian became CTO as part of the reverse management takeover. The Mach version underlying Openstep was updated for OS X, but kept around since Tevanian was very much a Mach booster.

NeXTStep was based on a Mach+BSD kernel, which at the time would've been an obvious thing to do if your goal was to create a modernized Unix system with all the latest cutting-edge (in the mid-80s!) technologies available.

That kernel lives on in OS X and its descendants. It was always built as a monolithic kernel, AFAIK. It just differed from a traditional BSD kernel in that the lowest layers (VM, process, thread, and scheduler stuff) were replaced by the Mach microkernel. I believe that this kind of monolithic Mach+BSD arrangement was a pretty common thing to do when developing a Mach-based Unix implementation.

From the outside it's almost indistinguishable from a BSD kernel. So why not just use an ordinary BSD kernel? Because it future-proofs the design. It gives you an easy path to gradually moving kernel-space services out of the core kernel and into separate address spaces, as microkernel technology improves and it becomes practical to do so. Of course, that never really happened, but it was a very logical choice at the time.

There were other benefits to Mach- you also got multithreading (this was a big deal, mid-80s remember), as well as Mach IPC. Mach IPC has its pros and cons, but just being able to have user and kernel services communicate via arbitrarily defined protocols rather than having to constantly add new system calls is very convenient.

That's pretty much it. This system has been around for > 30 years now, and even though it never turned into a true microkernel system, there probably was never much of a reason to de-Machify it either. It would be a ton of work and you wouldn't gain anything. It's not that Mach is so awesome (although it has some niceties), it's more that there's a lot of momentum there, and you wouldn't really gain anything by rewriting all that code.

As for why Linux distributions don't use it, the same reasons apply. It'd be too much work for relatively little benefit. It made sense to base your cutting edge kernel on Mach in 1985, not so much 30 years later. It doesn't make sense for OS X to stop using it for the reasons given above, but it also doesn't make much sense for anyone who isn't already using it to base new stuff on top of it today.

This was all pre Cathedral and Bazaar (1997) so Linux wasn't really on the radar at most companies.

EDIT: I'm thinking back... I was pretty young at the time 14-15 yo. And just learning to program, and what I really loved about BeOS was how easy the API was to learn. I had been learning C/C++ in MachTen and never could wrap my head around making Machintosh GUI applications. But sitting down with the Online documentation in BeOS, it was VERY easy to make a program with 3D graphics and a native GUI. Later on, QNX gained a lot of popularity I think for the same reasons (fantastic documentation and API). I had worked on a project under Solaris which relied on POSIX.4 extensions (yikes) before moving it to QNX.