5 ms·

Why do people implicitly assume that micro kernels are the best OS design? In fact, micro kernels have a lot of issues and limit the possibilities of what an O

by afr0ck 5y ago

Why do people implicitly assume that micro kernels are the best OS design? In fact, micro kernels have a lot of issues and limit the possibilities of what an OS can do! One of the most important issues is they prevents resource sharing in a rich and efficient way between the components of the kernel. They make building rich relationships between kernel data structures and kernel subsystems very messy, complicated, impracticable and very inefficient. Micro kernels are delusional and people should stop implicitly assuming their superiority.

sumtechguy 5y ago
Message passing at first seems interesting and neat and useful. It is for some cases. But it comes at a cost of complexity and latency.
PaulDavisThe1st 5y ago
This is a limitation of the memory model, not the microkernel. If you had a single hardware-protected address space, kernel modules could share resources freely. But this does argue against message passing, since such systems preferentially try to use messages over sharing whenever it's possible.
elihu 5y ago
Historically, one of the main arguments against microkernels is that having a kernel that's broken up into a lot of threads that each have their own hardware-enforced memory protection and use message passing to communicate with each other is dreadfully inefficient. All those context switches are expensive, and copying all that data around when you send messages is expensive. Rust's memory model largely makes those isolated address spaces unnecessary, and sending a message at runtime basically amounts to copying a pointer. So, with these performance issues resolved, I think it makes sense to look at microkernels again. The reasons why Linus was opposed to writing Linux as a microkernel in the 90's don't necessarily still apply now in 2021. There may some things the Linux kernel does that can't be efficiently expressed using a message-passing style, but I don't know if that's actually true or not.
- adwn 5y ago
  > Rust's memory model largely makes those isolated address spaces unnecessary, I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need an unsafe block and std::ptr::write. There's nothing about Rust that could replace isolated address spaces. Rust is typically compiled to native machine instructions, there's no sandbox or virtual machine that will protect different modules from each other.
  - globular-toast 5y ago
    I think we have to assume that people aren't putting malicious code into the kernel, don't we?
    - imtringued 5y ago
      The kernel will have a lot of "unsafe" (the keyword) code.
    - adwn 5y ago
      But that's one of the big promises of micro-kernels: You don't have to have 100% trust in the driver for that gamepad you bought from some unknown company. What about that WiFi driver with 10,000s of lines of code? Are you absolutely sure there isn't some code in it that accidentally or purposefully leaks the rest of your kernel data structures to the outside world? With drivers in their own isolated address space, you wouldn't have to be.
      - magicalhippo 5y ago
        That was the point behind Singularity OS[1] IIRC. Using managed code which could be verified safe by the OS using static analysis. Can't find it right now, but I recall reading they implemented a network driver with minimal overhead compared to a traditional OS. While they used message passing, a lot of overhead could be eliminated due to the assumptions of safe code. [1]: https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 https://en.wikipedia.org/wiki/Singularity_%28operating_syste...

by afr0ck 5y ago

sumtechguy 5y ago

Message passing at first seems interesting and neat and useful. It is for some cases. But it comes at a cost of complexity and latency.

PaulDavisThe1st 5y ago

This is a limitation of the memory model, not the microkernel. If you had a single hardware-protected address space, kernel modules could share resources freely. But this does argue against message passing, since such systems preferentially try to use messages over sharing whenever it's possible.

elihu 5y ago

Historically, one of the main arguments against microkernels is that having a kernel that's broken up into a lot of threads that each have their own hardware-enforced memory protection and use message passing to communicate with each other is dreadfully inefficient. All those context switches are expensive, and copying all that data around when you send messages is expensive. Rust's memory model largely makes those isolated address spaces unnecessary, and sending a message at runtime basically amounts to copying a pointer. So, with these performance issues resolved, I think it makes sense to look at microkernels again. The reasons why Linus was opposed to writing Linux as a microkernel in the 90's don't necessarily still apply now in 2021. There may some things the Linux kernel does that can't be efficiently expressed using a message-passing style, but I don't know if that's actually true or not.

adwn 5y ago
> Rust's memory model largely makes those isolated address spaces unnecessary, I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need an unsafe block and std::ptr::write. There's nothing about Rust that could replace isolated address spaces. Rust is typically compiled to native machine instructions, there's no sandbox or virtual machine that will protect different modules from each other.
- globular-toast 5y ago
  I think we have to assume that people aren't putting malicious code into the kernel, don't we?
  - imtringued 5y ago
    The kernel will have a lot of "unsafe" (the keyword) code.
  - adwn 5y ago
    But that's one of the big promises of micro-kernels: You don't have to have 100% trust in the driver for that gamepad you bought from some unknown company. What about that WiFi driver with 10,000s of lines of code? Are you absolutely sure there isn't some code in it that accidentally or purposefully leaks the rest of your kernel data structures to the outside world? With drivers in their own isolated address space, you wouldn't have to be.
    - magicalhippo 5y ago
      That was the point behind Singularity OS[1] IIRC. Using managed code which could be verified safe by the OS using static analysis. Can't find it right now, but I recall reading they implemented a network driver with minimal overhead compared to a traditional OS. While they used message passing, a lot of overhead could be eliminated due to the assumptions of safe code. [1]: https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 https://en.wikipedia.org/wiki/Singularity_%28operating_syste...