Kernel: Monolithic vs Micro

Kernel: Monolithic vs Micro

Kernel is the core of the Operating System(OS), and roughly consists of two parts: the kernel space (privileged mode) and the user space (unprivileged mode)without that, protection between the processes would be impossible.

There are two different concepts of kernel: Monolithic kernel and Micro-kernel. The older approach is the Monolithic kernel, of which Unix, MS-DOS and Mac OS are typical represents of. It runs basic system services like process, memory management, interrupt handling, I/O communication, file systems in kernel space.

Monolithic kernel

The inclusions of all basic services in kernel space has three disadvantages:

Ø       The kernel size

Ø       Lack of extensibility

Ø       Bad maintainability

Bug fixing or addition of new featured means re-compilation of the whole kernel which consumes lot of time as well as lot of memory.

To overcome the above disadvantages micro-kernels was introduced in late 1980’s. The concept was to reduce kernel to basic process and I/O, memory system services reside in the user space (they are called as servers). There are servers for managing issues, another server for managing drivers and so on... Communications happens through Context switching where user processes are allowed to kernel space and then exit. Messaging system was introduced which has independent communication for process rather than context switching which consumes more memory.

Micro-kernel

First generation of micro-kernel was had a lot of drawback concerning IPC, device drivers, communication stacks which resulted in larger kernel size which was slower in execution.

Later was thought to create a pure micro-kernel where it fits to processor’s first level cache. Second generation micro-kernel (L4) was highly optimized which results in a very good I/O performance.

Important Parameters in Comparisons:

Memory management:

Monolithic kernel:

Monolithic kernels implement everything needed for memory management in kernel space. This includes allocation strategies, virtual memory management, and page replacement algorithms.

Monolithic - Memory Management

Micro-kernel:

Micro-kernel L4 has got three memory management primitives: map, grant and flush. A process maps memory pages to another process if he wants to share these pages. When a process grants pages to another process, he cannot access them anymore. Flushing regains granted and mapped memory pages.

Micro-kernel - Memory Management

The micro-kernel reserves the whole system memory at startup to one process, the base system process, which resides (like all other processes) in user space. If a process needs memory, he doesn't have to take the way through the kernel anymore, but directly asks the base system process. Because every process can only grant/map/flush the memory pages it owned before, memory protection still exists.

I/O Communication:

Monolithic kernel:

I/O communication works through interrupts, issued by or sent to the hardware. Monolithic kernels run device drivers inside the kernel space. Hardware interrupts are directly handled by kernel processes. To add or change features provided by the hardware, all layers above the changed layer in the monolithic kernel also have to be changed in the worst case.

The concept of so called modules was introduced to achieve more independence and separation from the kernel. One module represents (parts of) a driver and is (un)loadable during run time. That way, drivers which are not needed by the system are not loaded and memory is preserved. But kernel modules are still binary kernel-dependent. If concepts change too much inside the monolithic kernel, modules need not just a recompilation, but a complete code adoption.

Micro-kernel:

The micro-kernel approach doesn't handle I/O communication directly, It only ensures the communication. Requests from or to the hardware are redirected as messages by the micro-kernel to the servers in user space. If the hardware triggers an interrupt, the micro kernel sends a message to the device driver server, and has nothing more to do about it. The device driver server takes the message and sends it to the right device driver. That way it is possible to add new drivers, exchange the driver manager without exchanging drivers or even exchange the whole driver management system without changing any other part of the system.