That's why I miss QNX. Tiny microkernel, yet the system can do almost all of POSIX. Driver are in user space. File systems are in user space. Networking is in user space. It's used widely for embedded applications, especially automotive, but since Blackberry took over and locked it down, access is expensive. Blackberry also killed off the QNX desktop environment and self-hosting. You used to build QNX on QNX.
L4 is even smaller, but too small. You have to run another OS on top of L4 to get anything done. QNX can run ordinary application programs. At one point there was a version of Firefox for QNX, and all of the GNU command line tools worked.
This suggests strongly that Mungi, iguana, and every other multi-server OS on L4 is a failure on a practical level. No doubt some papers were published and cited.
Question: Why did none of the operating systems written on L4 work on a practical level to get useful work done?
QNX is the one I have heard of most often when someone wants to tout a microkernel based OS success. In fact I've never heard another OS being suggested in that context.
Given the repeated claims about the benefits of microkernels, complexity management, better security, self-healing faults, lower bug density etc etc. Why isn't QNX the hottest OS that everyone wants to run for just about everything? Certainly everything that needs to be secure on a hostile network. Some might not want the performance trade off of essentially making your cache smaller so things run slower but plenty wouldn't mind that trade off at all. Yet it hasn't taken off or even gotten a toehold that I can see. Nobody has ever tried to sell me QNX for anything. Remember pwn2own and the various variants - never saw QNX even entered there...
Why is that? I feel like there is something being left out of the standard discussion of these things that is crucial. RMS said Hurd didn't work out because it was really hard to debug. Is that it? Is there some other reason why microkernels are just too hard to deal with? Are the benefits a bit illusory? Is it something else?
These are genunine questions. Usually when I ask them I'm met with a wall of unsubstantiated claims and anger bordering on abuse. But still no microkernel based OS I can run to do useful work. I wish I understood why I don't have a microkernel based OS to even play with better.
Having met many QNX people back around 2003-2005, their problems were:
1. Microsoft had the OS business locked up.
2. QNX cost more than Windows.
3. Their marketing was not very good.
Then QNX, the company, was sold off to an audio company. That was a disaster. Then it was sold again to Blackberry. Along the way, they went from closed source to open source to closed source to open source to closed source. This antagonized the QNX user community. QNX relied on ports of GCC, Eclipse, etc. for development, and all those communities stopped supporting QNX.
Right now, you can still buy QNX. But not on line. You have to talk to a sales rep. If you have to ask how much it costs, you can't afford it. It's widely used inside things like car dashboards. The classic line is "you use Linux to run your web server, and QNX to run your nuclear power plant."
They've been terrified of people pirating it. I used to tell their people that their problem was not piracy, it was being ignored.
They should have a business model like Epic has for Unreal Engine - anyone can download and use it for free, and when you get over $100K in revenue, they get 5%. Although that's easier to enforce in gaming, because few titles hit $100K in revenue and those are easy to find.
(Some years ago QNX had a sales win with a major auto manufacturer. They'd been considering an embedded version of Windows. Microsoft insisted that the Windows splash screen appear when the dashboard powered up. This was not well received by the auto company, and they went with QNX.)
L4 microkernels are actually pretty widely deployed in cellular phone / tablet baseband processors (the real-time stack that actually handles communicating with the cell tower), including some iPad models.
As far a cache, depending on what's going on, you may find lower cache usage. In school, I had an assignment to run a simulated filesystem benchmark and identify the sizes of various caches on my system from the benchmark results. I was quad-booting Linux, L4Linux, QNX, and Win2k on my desktop at the time, so I ran the benchmark on Linux, L4Linux, and QNX. QNX actually showed better cache utilization than Linux (bigger filesystem working sets before noticeable percentages of cache misses at the various levels). If your kernel is extremely small, it has good cache locality, likewise for a small fs driver. So, if you're really hammering just one application and one or two drivers, you might get better cache utilization from a microkernel.
The KVM example is sort of weird to me: the goal of that code inside KVM is to provide a comparatively "easy" interface for creating VMs on multiple architectures. The code isn't particularly motivating if you don't see how it's used.
Until you get pretty deep into the weeds, none of KVM's code can actually do anything architecturally specific, since all of the glue code is architecturally agnostic. KVM supports a ton of architectures, intel-x86/amd-x86/armv/s390/risc-v/...
On top of that, KVM tries to avoid having extra ioctls (essentially KVM syscalls). A lot of the ioctls are so flexible that they don't really tell you anything about what a CPU should* look like. The ioctls let you create a VM that is in essentially any valid state a CPU could reach (since VMs need to be migratable).
Take a look at the sample code in the rust kvm-ioctls crate [1] and you'll see what defines a VM.
1) Open the KVM fd for access to the ioctls.
2) Make the VM fd.
3) Make guest RAM, and shove the asm from up above into it.
4) Make a vCPU.
5) Initialize the registers for the vCPU.
6) Run the VM, and handle the exits (KVM sometimes can't handle what the VM is doing and returns to usermode to have them deal with it. Think device emulation).
This avoids initializing a lot of state for the VM, but it's enough to run it. Notable details are things like CPUID (supported cpu features for the VM), the Interrupt Descriptor Table, and the control registers. If this VM took an exception/interrupt right now, it would immediately triple fault. This sample VM is running in "real mode" (16-bit unpaged mode).
I put Haiku on a memory stick and tried to boot an 11" MacBook Air 2013. It just showed the boot screen, nothing more - no GUI, cursor, or command line.
I'm not sure I exactly get what "separation kernel" means. The linked wikipedia page doesn't help much. But the description of the problem leads me to unikernels as the answer.
It's interesting to think of alternative operating systems, but some things are pretty much locked to the mainstream OSes. For example, Nvidia's hardware.
Yes, this is one of the harms of proprietary software (including drivers) - you’re limited to what the developer intended.
It’s similar to the issues you have with non-x86 architectures. If I have an ARM laptop and I want to run a proprietary application on it that was compiled only for x86... well, I largely can’t. (Microsoft and Apple have both had to develop translation systems for this independently, and it slows things down and eats battery life. At least MS’s implementation, we don’t know much about Apple’s yet.) Contrast that to free software applications, where distros like Debian have thousands of them available in the repositories for all supported architectures, and you can build them yourself if they’re not in the repos.
If you want alternative OSes to be an option, buy hardware that runs with free software.
L4 is even smaller, but too small. You have to run another OS on top of L4 to get anything done. QNX can run ordinary application programs. At one point there was a version of Firefox for QNX, and all of the GNU command line tools worked.