Err.. loading drivers dynamically according to a stable ABI doesn't make an OS a microkernel. If the drivers all share the same address space that's a pretty conventional OS. For a microkernel you need to have separate processes for each driver. It's more robust but there's more IPC overhead.
I think the infrastructure required for a microkernel would have more features than this OS. It really is incredibly barebones and that's why it is monolithic. That being said, I guess it's maybe possible.
Under no circumstances, it’s a microkernel for embedded systems.
It’s like asking under what scenarios would you want to drive an ATV through New York. Technically possible, but that’s just not what it was made to do.
IMO a microkernel isn't a design worth pursuing as there will always be overhead. Instead an exokernel with a simple monolithic 'multiplexing' kernel or a language that has 100% safety (not really possible).
Since microkernels are not popular (at least not open source ones, and the closed source often don't give enough data to know) that isn't even meaningful. We would need a full-features microkernel based OS that tried to do it correctly. Otherwise it could be easier to do, but nobody tried.
Not only was it perfectly possible, microkernels have been sold commercially for decades and are extremely popular in hard real time environments where you want to be able to pre-empt a driver as though it is just another user process (which they are!).
That might still be an argument in favor of microkernels if the Linux process can't crash the machine or cause it to miss hard-real-time deadlines. Or if you can use it to confine malicious code in the Linux process.
Microkernel does seem the only sensible path forward. Even if the kernel is slowly rustified, going to be playing security whack-a-mole for a long time.
reply