Multikernel architecture proposed for Linux
26 points by gnafuthegreat
26 points by gnafuthegreat
So this is me not reading the references but: how do you handle like interrupts and such? Is there a dom0 kernel that does that?
Me not reading the references either, but I'd venture a guess that you'd have to bind each hardware resources to a specific kernel (and thus core) and handle all the interrupts on that core (or set of cores I suppose). I'd also guess that there has to be protocols for sharing use of the resources among kernel instances. Maybe make it more microkernel-like, with message passing between the cores?
One interesting thing that could be done is to isolate things that are prone to be exposed to untrusted things, like USB and Ethernet, in separate kernels with limited access to the rest of the system. Then an exploit might be able to interfere with the IO-handling kernel but not gain access to all RAM etc.
I’ve not looked at this specifically, but similar approaches are used in HPC where you use the kernel’s CPU hotplug support to hand a few cores over to a lightweight runner. This works by using modern interrupt controllers’ support for routing interrupts to specific cores. The initial kernel is set up to do that, but there’s no reason you couldn’t hand control over the interrupt routing over to the second kernel.
I am worried about increasing complexity that creeps in over the course of decades.
At some point someone will probably be fanatic enough to just rewrite everything in whatever comes after Rust, though.
At some point sure, but plenty of parts of linux have already gone through this I'd guess. It's the circle of software life.
Looking at the discussion, it doesn't seem like the community is super bought-in into the idea.
One response does link to https://multikernel.io/ which seems to have more context.
I don’t know how to suggest a merge but this is the same story as https://lobste.rs/s/jjqdal/multikernel_architecture_proposed_for
Good call out!
There is a flag button under the post title, you can use that to mark it as "Already Posted"
Wonder how this works with the typical pattern of having a "junk core" to run everything that isn't your app. Presumably each kernel still has some background work it wants to do so this isn't a real isolcpus alternative, is it?
Not a single mention of Helios.
https://github.com/axelmuhr/Helios-NG
This looks like Helios half-merged with the ideas of Inferno.
Those who do not know their history are doomed to repeat it.
It's time for Greenspun's eleventh rule:
Any sufficiently complicated Linux deployment contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9 and/or Inferno.
Plan 9:
Containers in general, Kuberenetes, KVM, Xen...
Inferno:
Wasm, eBPF, all language VMs...
Which ideas from Inferno do you see in this proposal?
Well, from https://multikernel.io/2025/09/18/multikernel-goes-open-source/ …
« Our multikernel architecture stands on the shoulders of giants, drawing inspiration from pioneering research in replicated-kernel systems, particularly Popcorn Linux, which has demonstrated innovative approaches to multi-kernel architectures and cross-ISA execution environments. »
That links to https://popcornlinux.org/ which says:
« Popcorn Linux uses an LLVM-based customized compiler that translates C/C++ applications into machine code suitable for execution and runtime migration across multiple instruction set architectures. »
Does that make it clearer?
Not really. You haven't drawn the Inferno connection yet.
It seems to be more of a focus of Popcorn Linux, which was apparently an (or possibly the primary) inspiration for this multikernel project, to be able to create binaries that could run on multiple different CPUs with different ISAs: instruction set architectures.
This was also the primary differentiating characteristic of Inferno. C was mostly replaced by Limbo, a safer C-like language, which compiled to bytecode that ran on Dis, an in-kernel VM that meant that binaries could run on multiple different CPUs.
The multikernel aspect reminds me of Helios, which was designed for (at its time) massively parallel systems with many CPUs, and which ran one tiny kernel on every CPU which communicated with one another, rather than one kernel with one memory space executing with multiple threads. HeliOS seems like a natural fit for manycore systems today. These don't get the press so much but they are still a thing; e.g. Intel still makes octocore Atom CPUs in 2025.