That still leaves lots of functionality in the kernel, most notably the BSD code (which implements Unix syscalls). So even with the new userspace driver support, most people would not consider xnu a microkernel.

It will be very hard to be a monolithic kernel without any sort of kernel space drivers.

Also many BSD syscalls have been deprecated along the years, including POSIX features like networking stack, now replaced by Objective-C APIs.

I would advise spending some time reading "Mac OS X Internals: A Systems Approach" and "Mac OS X and iOS Internals" books, to learn that having everything on kernel space alone, doesn't rewrite the original microkernel code into a huge monolith.

Userspace drivers do not make a microkernel.

They surely do when there isn't anything else available.

Apple showed their long term roadmap at WWDC how they plan to purge all kernel drivers.

Including file systems, graphics and networking? That sounds like it would require a redesign of Mach, similar to what the L4 family had to do, or what Google is doing with Fuchsia.

Networking - as in from the packet queues down, yes. I could see the IP stack making its way into its own process (or more likely they'll try and see that the perf is terrible). Of they do that, they'll probably push SSL into the same stack.

Graphics - I don't see much changing, but to be fair it's pretty nice already. The part in kernel space for the most part just controls the GPU's MMU, the meat of the driver runs in user space for speed reasons as shared libraries in the processes that are making GPU calls. It's sort of exokernel like if you squint hard enough.

Filesystems - will probably be hybrid. I don't see APFS leaving kernel space, or anything your root partition would be on, but NFS, exFat, NTFS? Yeah.

That is what they mentioned at WWDC yes.

Networking is part of the first wave by the way.

Networking kernel drivers are now deprecated as you can easily read about here.

https://developer.apple.com/documentation/macos_release_note...

Are all drivers going to be userspace in Catalina, or just the user-installed kernel extensions? I just assumed Apple's OS drivers would still be in kernelspace.

Maybe I'm wrong, but I always thought that the "classic" description of a microkernel was one that implemented not only device drivers, but filesystem drivers and possibly other key components in userspace (memory manager?) as well. At least that is how I remember MINIX 1.0 as described in the Tanenbaum book.

I appreciate there is a lot of grey area with microkernels, and a lot of hybrid designs these days, since as was the case with Mach/XNU/Windows NT, "pure" microkernel designs have often shown less than optimal performance due to additional context switching.

Catalina is only the start of a long term roadmap, so no not all drivers are userspace on Catalina, just the first set of them.

Apple stated that would apply to everyone, as you can check from WWDC videos.

Have they solved the performance issue in any way?

QNX, L4 and Minix 3 have solved it ages ago.

Even current macOS variants do plenty of message passing and sandboxing.

From the iOS games and real time audio apps, it appears fast enough to me.

But they are fundamentally different. They have no mailboxes in the server, they just pass the messages through to the right client after some capabilities check.

Mach and Hurd on the other hand store the messages in the kernel, priorities them and handles all mailbox messages, without ever losing one. This proved to be the wrong approach.

Seems to work alright for consumer media in real time, something that monolithic Linux has real issues with.

I think that just goes to show that when it comes to consumer media, there's probably more important layers in the stack that should be the focus of optimizations.

Lack of hardware acceleration, and the general clunkiness of X windows make Linux crappy in this regard for example. I _still_ get screen tearing in Ubuntu 18.04 if I don't run Wayland, which I don't because it breaks some apps I use.

For consumer media it's even more important to drop late or lost messages. Just like with its transport protocol RTP or UDP. A microkernel is much, much simplier than those protocols.

There are no proper L4 performance comparisons.

A few benchmark L4Linux, where L4 is not used as a microkernel but a hypervisor which consequently proves nothing about the micokernel paradigm.

I've forgotten it's title, but there was a performance comparison between Linux and MkLinux (with the OSF/Mach microkernel) in the one and only FSF free software conference. It had my favorite chart: a barchart showing the relative performance. The top half was 1:1; the bottom half was 1:2 or so.

The top half was Dhrystones (CPU integer performance), the bottom was various syscalls.

Section 2.1, table 1:4.

https://ts.data61.csiro.au/publications/nicta_full_text/8988...

An hypervisor is a kind of microkernel.

The benchmark is its use as radio OS on many handsets.

Yes, but...

This usage goes against many of the security claims of microkernels. In particular. If Linux is big and insecure running it in a VM doesn't really improves its security. It just make sure it doesn't infect the rest of the system. For this type of benchmark the "rest of the system" does not exist.

(I assume you meant the baseband processor in iPhone and Android. I don't think either use a clean microkernel and there isn't really a performance comparison available)

I prefer to see hypervisors used alongside Unikernels in what concerns security.

For me the benchmark that counts is "does it deliver in production", winning ms in laboratory micro-benchmarks is kind of useless.

Specially when so many are willing to waste those ms running Electron apps on userspace.