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
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.
reply