Device drivers as separate processes might not improve much the resistance against intentional exploits, but they would certainly greatly improve the resistance against bugs.

There are parts that are so simple that it can be practically guaranteed that they are bug free, e.g. the keyboard driver. Also the microkernel itself can be practically bug-free.

A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer.

On Linux I have seen cases when the GPU crashed, but switching to a virtual console and back avoided the reboot, by reinitializing the GPU, but I have also seen crashes when not even the keyboard worked, which should never happen, so a reboot was the only solution.

With device drivers in separate processes, bugs in one should not corrupt the memory of others, so restarting a device driver should be enough, instead of rebooting the computer.

> Microservices need to know who to call how

Here there is no difference between a monolithic kernel and a microkernel. With a monolithic kernel, the applications need to know which syscalls to use.

Libraries like libc or liburing can be implemented either by using syscalls to a monolithic kernel or messages to the processes that own peripheral devices, without any change in the API used by application programs. Obtaining memory pages shared with device driver processes can be done by creating file mappings for some pseudo-files with standard names, which has no essential difference from doing I/O by opening device nodes from the /dev pseudo-filesystem in UNIX-like OSes.

Any complex program must be designed from the beginning to be easy to test and debug. If the device drivers are distinct processes, there is no reason to be more difficult to debug them. On the contrary, because the interactions between them are more limited than when they live in a common address space, they should be easier to debug.

A micro-kernel with the associated device driver processes would contain more or less the same code that is now included in the Linux kernel or in any other monolithic kernel but it would be separated in multiple parts with clear boundaries and interfaces between them.

This can only make much easier the reasoning about how the entire system works. The downside is that the interfaces must be well defined. The history of Linux shows a huge number of badly defined interfaces, which later had to be changed. Even in the syscalls, which are supposed to be stable, there are many syscalls already at their fourth or fifth variant, with the previous variants still kept around despite being obsolete, for backwards compatibility with legacy programs.

Nevertheless, defining good interfaces is not that difficult, especially today when there is much less pressure to save every bit in a parameter list (even when taking into account the current memory prices). Most Linux interfaces that had to be replaced were replaced for not having features that were obvious as necessary since the beginning, e.g. for not having a parameter with option-encoding flags or for using some data types that were too small.

> A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer.

Yes, it should be. I can name zero times in the past half-decade that it's been possible to soft-reset the hardware in my GPU.

The "reset the GPU switch" is the power switch on my computer.

That's true of most hardware. If my ethernet, wifi, or whatever else enter an unstable state, on paper, the monolithic kernel can do the same thing as the microkernel: unload the module, then reload the module. In practice, I've virtually never seen a driver able to pick up a piece of hardware in an unstable state and be able to "reset" it.

> With device drivers in separate processes, bugs in one should not corrupt the memory of others, so restarting a device driver should be enough, instead of rebooting the computer.

Device drivers can corrupt other devices easily enough. The hardware itself would need to be built for isolation.

> Any complex program must be designed from the beginning to be easy to test and debug. If the device drivers are distinct processes, there is no reason to be more difficult to debug them. On the contrary, because the interactions between them are more limited than when they live in a common address space, they should be easier to debug.

That's exactly the myth.

In practice, a complex data flow for a heisenbug might start at the network layer, go through the disk, and land on the GPU. Tracing that on a microkernel requires instrumentation which, while possible in theory, I've never seen in practice.

I'd love to see a hardware stack where everything is ECC, devices are isolated, etc. but for now, on a typical computer, plugging in a bad USB device can brick the whole system (regardless of the software on it). The assumption is that devices on your PCIe bus can be trusted.

> This can only make much easier the reasoning about how the entire system works.

You make very strong statements, without support.

There's a reason Linux runs on every Android phone, almost every router, and increasingly, devices like home microwaves.

Funnily enough, "GPU" (video driver) on Linux used to be microkernel-like: the Xorg would run in userspace and talk to device directly. It was exactly as you described - if Xorg crashed, you could use keyboard shortcut to reinitialize it.

And the major motivators for KMS/DRM, which moved a lot of that functionality into kernel, was performance and stability.

The asahi Linux gpu driver has gotten pretty darn close to being very solid.