0
$\begingroup$

I don't understand the last para. I corrected its typos. Please explain like I'm 5. If micro-kernels can be big, and monolithic kernels can be small, doesn't this size gradation collapse the distinction between monolithic kernels and micro-kernels? Is this what a hybrid kernel means?

So.. that's the ELI5 version. Things change, microkernels was going to be the cool logical way to do it, that argument between Tovalds and Tanenbaum really is worth a read. But Monolithic kernels appear (for now) to have won, as they want speed, instant access to resources (like kitchens or GFX cards) and rely on the OS managing processes a bit smarter to figure out who gets what type of access at what time. But just because a kernel is micro doesn't mean it won't take a lot of room up, as it'll then still need all the drivers to do things and be useful. So you can have a monolithic kernel that's small (compiled with only the drivers it needs into the kernel), and a microkernel that's big (compiled for a certain architecture/memory configuration with lots of modules available to handle all sorts of odd hardware to be plugged in). Google will provide more details and far more pros/cons that we can throw here. But again, read that linked Torvalds/Tannenbaum argument, it's the kind of thing that still goes on today.

enter image description here

$\endgroup$

1 Answer 1

3
$\begingroup$

The distinction between monolithic kernels and microkernels has nothing to do with the size.

In a monolithic kernel, all services are provided by a single piece of code running in a single, flat, shared address space. There are monolithic kernels which support dynamically loadable modules now (actually most monolithic kernels do), but when these modules are loaded, they still become part of the single monolithic (hence the name!) blob of code running in the single address space. All communication between these different services is done by accessing shared memory, or another way of looking at it is that there is no communication because it's all just one singular monolithic blob of code.

In a microkernel, only the most basic, fundamental services are provided by the kernel. Everything else is provided by separate programs, which are separate pieces of code, running in separate address spaces. All communication between the services is done through a well-defined messaging protocol.

So, in a monolithic kernel, you have a single piece of code which manages memory, schedules tasks, accesses the disk, accesses the filesystem, accesses the network card, implements the TCP/IP stack, implements Ethernet, implements WiFi, access the graphics card, etc.

In a microkernel, the kernel only implements the very basics: memory management, task scheduling, and a simple messaging protocol that allows the programs to talk to each other and to the kernel. The disk driver is a separate program. The filesystem driver is a separate program. The network card driver is a separate program. The implementation of the IP protocol is a separate program, TCP is a separate program, UDP, IPv6, etc. are all separate programs. The Ethernet implementation is a separate program, actually probably a set of separate programs for the PHY layer, the LLC layer, the MAC layer, etc. Same for WiFi, that's going to be a whole set of separate programs. The graphics driver is a separate program. And so on, and so forth.

These "separate programs" are sometimes calls "services" or "deamons".

The relationship between a microkernel and its daemons is analogous to the relationship between an Operating System and the user programs: Your browser, your email program, your first-person shooter, your music software, your text editor, your chess program, your video editor, your drone controller, your video chat program, they are not part of the Operating System. They are all separate programs that run in separate processes in separate address spaces. One of them can crash without taking the entire system down.

But none of this has anything to do with size: the sum of a microkernel and many services that provide many features can be larger than a simple monolithic kernel that doesn't provide many features. If a system doesn't support networking, for example, then it doesn't need code for networking, regardless of whether that is a microkernel or a monolithic kernel. So, it is easily possible for a microkernel system that supports networking to be larger than a monolithic kernel system that does not support networking.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.