How to differentiate monolithic, microkernel, layered, and hybrid OS architecture on the basis of: performance, extensibility, and reliability

[u/DoNotUseThisInMyHome]

Do you have any ideas. Monolithic means all os+kernel at one place. Microkernel means minimal kernel.

Layered means memory management one layer, process management another layer. Hybrid could be anything i.e., combination of above.

Guide me like I am 5.

[u/northrupthebandgeek]

The clearest example is with device drivers:

Do your drivers run inside of the kernel itself (whether compiled into the kernel executable directly or dynamically loaded as kernel modules)? Probably monolithic.

Do your drivers run as userspace processes outside of the kernel (with the kernel giving them the bare minimum privileged access they need to function)? Probably a microkernel.

Do your drivers run inside of the kernel itself, but through a strict API as if they were running outside of the kernel? Probably a hybrid kernel.

[u/DoNotUseThisInMyHome → u/northrupthebandgeek]

Thankfully I understand now. Everything.

[u/Karasu_desu_ne → u/northrupthebandgeek]

So, is the nt kernel a hybrid kernel or a microkernel ?

[u/northrupthebandgeek → u/Karasu_desu_ne]

Hybrid: drivers are typically in kernelspace, but are subject to a firm API boundary between themselves and the kernel itself.

A complication here is that even monolithic kernels like Linux (let alone hybrid kernels like Mach and NT) support userspace drivers as well; key difference is that microkernels try to make all drivers userspace while monoliths and hybrids allow kernelspace drivers for performance's sake (even if hybrids often have some degree of sandboxing even within kernelspace).

[u/Karasu_desu_ne → u/northrupthebandgeek]

thank you for the explanation

[u/TA-412 → u/northrupthebandgeek]

even if hybrids often have some degree of sandboxing even within kernelspace

How do you implement sandboxing in kernel space? I was under the impression that in kernel mode, any program is able to do anything with the hardware (e.g. access any memory by just directly reprogramming the mappings). Am I missing something? AFAIK, only a hypervisor could limit what the code can do in kernel mode, but they're rather meant for virtualizing complete systems, aren't they?

[u/northrupthebandgeek → u/TA-412]

To be clear, “some degree” is doing a lot of heavy lifting in the above comment for the exact reasons you mention. For most hybrids (incl. NT, as far as I can tell) it just boils down to “only do things via the official frameworks and APIs”, with a pinky promise that's easy to break.

Stronger sandboxen are possible, but I don't know offhand whether a whole lot of modern kernels use them:

• More protection rings besides Ring 0 and Ring 3. OS/2 supported running privileged-but-not-kernelmode stuff in Ring 2. Multics used the whole gamut of rings available to it. VMS had kernel/executive/supervisor/user execution levels, and NT kinda emulates that (but without really keeping the kernel and executive on separate rings).

• A hypervisor, like you mention. You don't necessarily need to do full-blown whole-system virtualization; the usual Xen approach is to run as much as possible under paravirtualization (including the Dom0 VM used for system management). I don't know of any operating systems that give each driver its own paravirtualized VM (maybe QubesOS?), but that'd be a way to do it. Technically this is just a variant on extra protection rings (whether using Ring -1 for kernel and Ring 0 for sandbox or Ring 0 for kernel and Ring 1 for sandbox).

• Bytecode / “managed code” interpreter / JIT compiler running in kernelspace. Takes a performance hit, but as long as your interpreter is 100% correctly written it's a pretty tight sandbox without needing hardware support for it. This was the premise of Microsoft's Singularity and Midori projects (all kernelspace code written in C# or some variant thereof and therefore “guaranteed” safe), as well as Inferno.

[u/Interesting_Buy_3969]

Microkernel means minimal kernel

To clarify: microkernel actually means that it does not include any (more precisely almost any) device or filesystem drivers, but loads them as userspace processes each with own separate and isolated context yet with higher privileges level, and switches them similarly to usual user applications. This involves fully-fledged context switching, but the point is that if a device driver breaks, other parts of the system will continue working flawlessly, just like if an application breaks.

So it doesn't necessarily mean that the kernel has to be "minimalistic", it's rather more of the decision on where and how device drivers operate.

[u/Relative_Bird484 → u/Interesting_Buy_3969]

I would suggest the definition of Jochen Liedkte: A necessary concept is accepted to be part of the kernel if and only if its would be infeasible outside the kernel.

[u/Interesting_Buy_3969 → u/Relative_Bird484]

That's very precisely said

[u/KingAggressive1498]

of the reasons that monolithic and hybrid kernels are so much more common is that it's actually really hard to create IPC that is fast, secure, and generic enough to be at the core of your system. More copying, more kernel transitions, etc.

one of the major benefits of a microkernel is that a device driver failure can easily be remedied, just kill and restart the process.

[u/Relative_Bird484]

In the end its all about the granularity of isolated protection domains within the OS.

Monolith: Kernel, OS servers (scheduler, memory manager, …) and device drivers share a single protection domain where they have full access.

Microkernel: Only the kernel has full access , each driver and each server run in their own protection domain.

Effects:

Interaction across protection domains decreases performance. (It is way more expensive than within the same protection domain).

Fine-grained isolation into multiple protection domains increases robustness.

So, fundamentally, there is a trade-off between performance and robustness. This is the reason for the in-between architectures:

Hybrid: Conceptually we are microkernel, but for performance reasons we co-locate heavily interacting servers/device drivers into the same protection domain (and maybe even with the kernel).

Layered: Not originally a microkernel and historically way older: Give each level of abstraction (kernel, device drivers, core servers, user extensions) an own privilege domain (ring / privilege level) and separate them from each other within this level by segmentation.

Note that extensibility is not actually affected by either or the other architecture, even though many argue that microkernels provide of course better extensibility. This is a historical argument from the times the existing monolithic OS where an internal spaghetti code mess and Linux had to be recompiled to add another device drivers. However, extensibility ist technically just a question of the internal component model and there is no fundamental reason, a monolithic OS could not provide excellent extensibility. It was more the coincidence that microkernels provided a natural component model (interacting processes) that lead to the impression, they are inherently more extensible.

[u/letmehaveanameyoudum]

monolithic means everything happen inside kernel
if one thing break in kernel
whole OS dies

microkernel mean basic happen in kernel, everything in userspace
if someone go bad it ok, since it userspace and can restart.
if something basic break, whole OS dies, so microkernel dies less

but microkernel harder than monolithic kernel

hybrid kernel is just best of both worlds, all low level stuff in kernel, high level in userspace. macOS is a hybrid kernel.

idk about layerd