Hacker News Reader

Comment by xvilka | Hacker News Reader

Another approach would be to go all in into improving the kernel [1] completely written in Rust, like in RedoxOS[2].

[1] https://gitlab.redox-os.org/redox-os/kernel

One of the main value propositions of Linux compared to any such alternative are thousands of drivers for almost any device that you can find on the market. Unless you find somebody willing to port them, I see very little practical sense in doing this (unless your goal is to have fun).

Moreover, for many critically important pieces of hardware, such as ARM Mali GPUs, the drivers are only available for Linux and Android.

Why not include support for running those 'legacy' C drivers in that new Rust kernel? Sure, you'd be giving up some of the memory guarantees, but that's no different from when you include some Rust into the current kernel.

There's no stable ABI for drivers. So much even Linux kernel itself isn't compatible with its drivers without their constant maintenance.

There's not even a stable API for drivers. The interfaces they use get changed and rewritten all the time.

My pet conspiracy theory is they do this to discourage kernel forks, so that Linux doesn't become fragmented.

I think supporting linux drivers was already tried in other kernels (I remember a talk Andrew Tanenbaum gave at a FOSDEM) when he tried to incorporate them in Minix v3 and he and his team gave up in frustration.

I don't think we need as many kernel drivers as we have. Many of those drivers should never have been in the kernel in the first place. Userspace would have been adequate.

If something can be done from userspace, it should be done from userspace.

Legacy Linux drivers could be sandboxed in user space inside a fake Linux kernel environment, a bit like how captive NDIS used to provide a fake NT kernel for network drivers run under Linux.

Sounds like you’re suggesting a microkernel architecture. It’s not a terrible idea, but it’s not a new one either and it hasn’t gained a huge amount of traction.

Not practical. The Linux driver ABI is unstable. At best, your hypothetical microkernel will work on a subset of obsolete hardware.

Say you have a USB coffee maker with a custom kernel driver and you want to put that driver in userspace. Just take one specific kernel version that has that driver, build it as a microkernel (so the kernel runs as a user mode process) including that driver, and then make that driver talk to the rest of the system over a stable interface like dbus. (Think of something like UML.)

The fact that the kernel ABI is unstable is irrelevant because you're not relying on ABI stability. You're using a specific version of the core kennel paired with a specific version of the driver.

Ahh ic. That's very different from the example you gave, NDISwrapper (which does rely on the ABI stability of Windows drivers).

Yeah your kernel could totally support USB coffee makers using USB passthrough to a Linux VM as long as (1) you write a Linux daemon for each device that lets you talk to the hardware over RPCs from the host and (2) all application software that wants to talk to said hardware uses your dbus API. That's a hell of an ask, but it's doable.

But what about the xHCI drivers for USB? You still have to write that for every USB chip on the market.

What about file systems? I've been burned by FUSE performance.

What about GPU drivers? This sucks on Linux and it'll suck even harder on your hypothetical kernel.

Or any device that sits on the PCIe bus for that matter. There are so many drivers that rely on running in a shared address space with data structures and hardware state shared with the rest of the kernel. At the very least you'll have to support the 2 new motherboard chipsets that come out every year. To be clear, I'm just taking about desktops. Laptops and phones will be a whole new world of pain

Shame about the license.

Aside for what others said, a microkernel is much less performant than a monolithic kernel.

I thought Fuchsia was a microkernel? not to counter your point.

I think post meltdown / spectre the idea of a trade off between security and performance has gained more traction. Perhaps it’s not such a problem.

Reply on news.ycombinator.com