FRESH

Hacker News

Home

Maybe we should revisit microkernels

23 points by morkin

by Rochus

0 subcomment

Mach is not a representative proxy for “microkernels” in 2026.The L4 family demonstrated that Mach-like systems were slow because they put too much policy and too many abstractions in the kernel path, not because a minimal protection-domain crossing was intrinsically unaffordable. The article seems to rediscover, in a somewhat Mach/XNU-centered view, pieces of a design space the L4 community has already discovered and used for a long time. IOMMUs can improve the security and deployability of DMA and user-mode drivers, but barely make L4’s already-fast IPC fundamentally faster.

by gnufx

0 subcomment

Not the first time I've said this: the 1970s-era GEC OS4000[1] was really fast, like compared with everyone's VAX 780s, and we users benefited in the '80s. I don't know whether or not it was strictly a microkernel, but at least the moral equivalent; the nucleus was originally in (hard/firm)ware, but it was later emulated on different hardware. (I guess, but don't know, that "4000" and "nucleus" reflected Brinch Hansen's RC 4000 system -- which seemed really steam-driven in the '80s).
1. https://en.wikipedia.org/wiki/OS4000

by frognumber

3 subcomments

I think history has proven that this theory:
> Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in one subsystem only crashes that subsystem instead of crashing everything; if windows were a microkernel system then the crowdstrike bug would have just stopped some IT security staff from getting telemetry instead of being front page news. If linux were a microkernel system then the linux kernel team wouldn't be responsible for merging every driver for every hardware device, and wouldn't be responsible for vetting code that they would have to become experts on the inner workings of every chip supported by the linux kernel to properly vet.
Is false. In particular:
- A kernel-level exploit can almost always be escalated. If I control your filesystem, you're SOL
- A kernel-level crash in any subsystem brings down the whole system. If your file system crashes, or your GPU is in an unstable state, there is no coming back
- Modularity is a question of clear boundaries. Whether those are static linking, dynamic linking, or XML-RPC doesn't change the level of modularity.
And so on.
Basically, none of the upsides have panned out. On the other hand, code complexity explodes. Microservices need to know who to call how. The whole "a crash in one subsystem only crashes that subsystem instead of crashing everything" means every subsystem needs defensive code for things going wrong elsewhere. KLOCs go up, bugs/KLOC stay constant, and things get less stable.
Plus, it's hard to reason about systemically, and without excellent telemetry, neigh-impossible to debug.

by vsgherzi

1 subcomments

Errors in the code potentially mean killing the liveness of the system or worse corrupting the system in a poor state. Think the networking stack getting corrupted because of bad business logic.
Also very hard to debug

by inglor_cz

0 subcomment

Symbian OS was a microkernel. For each functionality, you would run a "server" with determined privileges, your apps would connect as clients and make use of the functionality that the server was providing them with - i.e. audio, Bluetooth, filesystem access etc.
It was very efficient, a 200 MHz Nokia could run respectable loads. But the API was hell, which wasn't caused by the microkernel architecture, but rather by inheriting mid-90s EPOC idioms.
With a normal C++ stdlib, that would have been a very fine environment indeed.

by theamk

1 subcomments

> The overhead was too high because computers in the 80s didn't have a way for a userspace process to directly access a particular hardware device.
Eh, no, author mixed things up. To access a hardware device, you need ioperm, which is at least 20 years old. (Well, not today, but it was sufficient back then...). IOMMU is completely optional.
The microkernel overhead was too high because any operation (even the one that does not need access to hardware, like reading file from file cache) required a context switch. This does not change with IOMMU. And while having multiple cores helps, you are trading context switch to intra-core cache invalidation and extra scheduling overhead (because no modern system can just have a single core spinning forever).