11 ms·

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux k

by mo_42 3y ago

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

dijit 3y ago
With Linux it makes sense to go with the one file approach because it's a monolith. The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control. I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually. The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.
- samus 3y ago
  We have something like this already on mobile phones. NFC chips and the radio are pretty much independent systems and the host system has to use message passing to talk to them. The OS as a micro kernel doesn't really yield benefits in this case. Graphics cards and other accelerators are trickier since they can also access main memory. Therefore, restarting its driver might not resolve the problem, and the whole system has to be rebooted anyways. Anyways, the system might not be that usable anymore if a critical driver keeps crashing and restarting...
nequo 3y ago
Linux is not a microkernel, whether you compile it with modules or as one file. In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.
- arp242 3y ago
  It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.
  - cies 3y ago
    Yes. But a Linux driver can crash the whole OS. In micro kernel land, most driver will not be able to do that. As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".
    - JdeBP 3y ago
      You're almost there. Yes, there's a narrower definition. Yes, that means that crashes are outwith the kernel. But no that only means that the circle around what bit is named "the kernel" is smaller. Importantly, it does not mean that it is impossible to "crash the whole operating system". Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the entire operating system relies upon, such as a central shared rendezvous server, or a server that handles "magic" values, or a central local security subsystem server, or a shared fundamental "personality subsystem" server, still crashes the entire operating system, no matter that the crash isn't in the part of the operating system that's labelled "the kernel". * https://jdebp.uk/FGA/microkernel-conceptual-problems.html https://jdebp.uk/FGA/microkernel-conceptual-problems.html
      - cies 3y ago
        I think now we need to define what's the "whole OS". From a user's perspective: the whole OS crashed (became unresponsive). But from a developer's perspective the OS worked, as it was still logging, responding to network, etc.
  - ilyt 3y ago
    Yeah but fact a part can crash without bringing rest down doesn't make it non-monolithic. The fact that driver bug in theory could overwrite any other part of the kernel is what makes it monolithic.
dale_glass 3y ago
The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. * Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway. * Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable. * For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with.
- senko 3y ago
  > The debate is sort of obsolete really. Microkernels are not obsolete (see seL4), but HURD unfortunately is. > Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so. > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. This would imply operating system developers (in any) OS are not that much interested in reliability of the system they're working on, which I don't believe is true. Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. > A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. * Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway. Microkernels aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel. > Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable. Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. > For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with. Ah yes, ye olde "just don't write bugs!" argument :-) More seriously though, I would agree with you that replacing GNU/Linux with GNU/Hurd will never happen. I just want to emphasize Hurd is not be-all and end-all of microkernels (even open source ones). In fact, it never was.
bjoli 3y ago
The L4 folks showed that it could be done with acceptable overhead. Since then I have been a microkernel fan.
- agumonkey 3y ago
  you run some microkernels on a regular basis ? then there's the minix3 approach with process respawning, lots of good ideas
- arp242 3y ago
  Can I run Firefox or Redis on L4? What's the performance of that compared to Linux?
  - Palomides 3y ago
    check out genode
    - arp242 3y ago
      As I understand it Genode "just" runs Linux for many real-world applications, but with extra steps (via a VM). Either way, that doesn't really answer the question what real-world performance looks like.
      - Palomides 3y ago
        I believe it can run chrome natively now and has a fairly robust POSIX layer, no idea on performance though
      - snvzz 3y ago
        >"just" runs Linux for many real-world applications, but with extra steps (via a VM). You can run a modern web browser, with 3d hardware acceleration, on Genode itself. It has Virtualbox support, which is super convenient for covering any functionality gaps, but you don't need that for the above. Virtualbox simply enabled the developers to dogfood Genode years ago already, instead of today.
ilyt 3y ago
> From a computer science perspective micro kernels make so much sense. Reality beats theory every day of the week. Communication and isolation is never free. > But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so. Whether it has modules or not have no bearing on whether kernel is monolithic or not
marcosdumay 3y ago
Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change. A proper microkernel isn't like Linux with a bunch of modules. It's something that can your game direct access to the GPU, while restricting access to a pseudo-root on your disk, and to an edited raw RAM that pretends the spyware from the game's DRM is running on the main system while it's actually sandboxed. You can do something like that in a microkernel because you can replace it piecewise for a single application. You can technically do something like that on Linux, but you will never manage to.
- snvzz 3y ago
  >Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change. RISC-V and seL4 cooperate closely, ensuring this does not apply anymore.
sneed_chucker 3y ago
It's just classic worse is better
dwaite 3y ago
A microkernel is has more processes, and those processes have their own state and their own MMU configuration. They have to pass data between themselves to communicate by exposing data and mapping memory regions/structures across, which otherwise could be a function call with a pointer. A monolithic kernel is either running or panicked, with either valid or invalid memory. The microkernel adds more failure modes - such as previously always present parts of the system going away, resetting their internal state, hanging, being upgraded on a live system, and so on. The costs of the protections and of IPC recovery are what push towards monolithic designs. Modern microkernels have had a lot of focus on those two areas - often being little more than memory management and IPC at the core. I'd say even though new microkernel systems haven't displaced the current ones, research on these newer "nano kernels" have borne fruit in various hypervisors.

by mo_42 3y ago

dijit 3y ago

With Linux it makes sense to go with the one file approach because it's a monolith. The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control. I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually. The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.

samus 3y ago
We have something like this already on mobile phones. NFC chips and the radio are pretty much independent systems and the host system has to use message passing to talk to them. The OS as a micro kernel doesn't really yield benefits in this case. Graphics cards and other accelerators are trickier since they can also access main memory. Therefore, restarting its driver might not resolve the problem, and the whole system has to be rebooted anyways. Anyways, the system might not be that usable anymore if a critical driver keeps crashing and restarting...

nequo 3y ago

Linux is not a microkernel, whether you compile it with modules or as one file. In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.

arp242 3y ago
It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.
- cies 3y ago
  Yes. But a Linux driver can crash the whole OS. In micro kernel land, most driver will not be able to do that. As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".
  - JdeBP 3y ago
    You're almost there. Yes, there's a narrower definition. Yes, that means that crashes are outwith the kernel. But no that only means that the circle around what bit is named "the kernel" is smaller. Importantly, it does not mean that it is impossible to "crash the whole operating system". Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the entire operating system relies upon, such as a central shared rendezvous server, or a server that handles "magic" values, or a central local security subsystem server, or a shared fundamental "personality subsystem" server, still crashes the entire operating system, no matter that the crash isn't in the part of the operating system that's labelled "the kernel". * https://jdebp.uk/FGA/microkernel-conceptual-problems.html https://jdebp.uk/FGA/microkernel-conceptual-problems.html
    - cies 3y ago
      I think now we need to define what's the "whole OS". From a user's perspective: the whole OS crashed (became unresponsive). But from a developer's perspective the OS worked, as it was still logging, responding to network, etc.
- ilyt 3y ago
  Yeah but fact a part can crash without bringing rest down doesn't make it non-monolithic. The fact that driver bug in theory could overwrite any other part of the kernel is what makes it monolithic.

dale_glass 3y ago

The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. * Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway. * Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable. * For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with.

senko 3y ago
> The debate is sort of obsolete really. Microkernels are not obsolete (see seL4), but HURD unfortunately is. > Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so. > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. This would imply operating system developers (in any) OS are not that much interested in reliability of the system they're working on, which I don't believe is true. Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes. > A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels. * Software is also far more complex. Great, your system theoretically can survive a video card driver dying. Too bad the compositor can't survive that, and the applications can't survive the compositor crashing, and at that point you might as well reboot anyway. Microkernels aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel. > Modern testing and debugging is excellent and having a system kernel panic is something that happens very, very rarely. It's not really worthwhile to change the system architecture for the sake of something than happens less often than I accidentally unplug my desktop's power cable. Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete. > For HURD specifically, if you're in need of extreme reliability today, C is probably not something you want to use. Rather than dealing with stuff crashing you probably want to write code doesn't suffer from such issues to start with. Ah yes, ye olde "just don't write bugs!" argument :-) More seriously though, I would agree with you that replacing GNU/Linux with GNU/Hurd will never happen. I just want to emphasize Hurd is not be-all and end-all of microkernels (even open source ones). In fact, it never was.

bjoli 3y ago

The L4 folks showed that it could be done with acceptable overhead. Since then I have been a microkernel fan.

agumonkey 3y ago
you run some microkernels on a regular basis ? then there's the minix3 approach with process respawning, lots of good ideas
arp242 3y ago
Can I run Firefox or Redis on L4? What's the performance of that compared to Linux?
- Palomides 3y ago
  check out genode
  - arp242 3y ago
    As I understand it Genode "just" runs Linux for many real-world applications, but with extra steps (via a VM). Either way, that doesn't really answer the question what real-world performance looks like.
    - Palomides 3y ago
      I believe it can run chrome natively now and has a fairly robust POSIX layer, no idea on performance though
    - snvzz 3y ago
      >"just" runs Linux for many real-world applications, but with extra steps (via a VM). You can run a modern web browser, with 3d hardware acceleration, on Genode itself. It has Virtualbox support, which is super convenient for covering any functionality gaps, but you don't need that for the above. Virtualbox simply enabled the developers to dogfood Genode years ago already, instead of today.

ilyt 3y ago

> From a computer science perspective micro kernels make so much sense. Reality beats theory every day of the week. Communication and isolation is never free. > But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so. Whether it has modules or not have no bearing on whether kernel is monolithic or not

marcosdumay 3y ago

Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change. A proper microkernel isn't like Linux with a bunch of modules. It's something that can your game direct access to the GPU, while restricting access to a pseudo-root on your disk, and to an edited raw RAM that pretends the spyware from the game's DRM is running on the main system while it's actually sandboxed. You can do something like that in a microkernel because you can replace it piecewise for a single application. You can technically do something like that on Linux, but you will never manage to.

snvzz 3y ago
>Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change. RISC-V and seL4 cooperate closely, ensuring this does not apply anymore.

sneed_chucker 3y ago

It's just classic worse is better

dwaite 3y ago

A microkernel is has more processes, and those processes have their own state and their own MMU configuration. They have to pass data between themselves to communicate by exposing data and mapping memory regions/structures across, which otherwise could be a function call with a pointer. A monolithic kernel is either running or panicked, with either valid or invalid memory. The microkernel adds more failure modes - such as previously always present parts of the system going away, resetting their internal state, hanging, being upgraded on a live system, and so on. The costs of the protections and of IPC recovery are what push towards monolithic designs. Modern microkernels have had a lot of focus on those two areas - often being little more than memory management and IPC at the core. I'd say even though new microkernel systems haven't displaced the current ones, research on these newer "nano kernels" have borne fruit in various hypervisors.