Kernel Architecture

An operating system itself consists of two parts: the kernel space (privileged mode) and the userspace (unprivileged mode).

There are two different concepts of kernels:

• ·  monolithic kernel.
• ·  μ-kernel (microkernel).
  

Monolithic

The older approach is the monolithic kernel, of which Unix, MS-DOS, and the early Mac OS are typical represents of.

•  It runs every basic system service like process and memory management, interrupts handling and I/O communication, file system, etc.
• It is constructed in a layered fashion

The inclusion of all basic services in kernel space has three big drawbacks.

• The kernel size increase
• Lack of extensibility
• The bad maintainability
• Bug-fixing or the addition of new features means a recompilation of the whole kernel.

Monolithic Kernel (Macro Kernel): Kernel Image = (Kernel Core+Kernel Services). When a system boots up entire services are loaded and resides in memory.

Example: Windows and Unix.

Microkernel

The concept was to reduce the kernel to basic process communication and I/O control and let the other system services reside in user space in form of normal processes.

The μ-kernel is not a block of system services anymore but represents just several basic abstractions and primitives to control the communication between the processes and between a process and the underlying hardware.

Micro kernel : Kernel Image = Kernel Core. Services are built into special modules which can be loaded and unloaded as per need.

Modular kernel integration: Kernel Image = (Kernel core + IPC service modules +Memory module +Process Management module). All other modules are loadable kernel modules.

Example: Linux kernel

Inter-Process Communication

A process means the representation of a program in memory. It may consist of smaller, programmer-defined parts called ”threads”. Threads allow virtually parallel execution of different sections of a program. A thread is the smallest unit3 of executable code. A process can consist of several threads.

The earliest concept of inter-process communication (IPC) is called signals. It is widely used in Unix systems. Signals are predefined numerical constants, e.g. KILL, STOP, etc., which are sent to a process by a user. This system is fast, but the problem is, that the signals have to be predefined numbers.

Another solution for communication is the so-called sockets. A process binds itself to one socket (or more), and ”listens” to it, i.e. from then on, it can receive messages from other processes. Most of the sockets are full duplex a socket, is also called server, while the other processes are called clients. 

A system more powerful than sockets are message queues. Built as a FIFO queue, a message queue stores all incoming messages, sent by other processes and sorts them, based on their priority. 

While monolithic kernels use signals and sockets to ensure interprocess communication, the μ-kernel approach uses message queues. 

Security and Stability

The protection of system processes from being modified by the user or other processes is an important feature of the kernel. With the introduction of multitasking (and multithreading) new problems arose, concerning isolation of memory and processes. These problems include issues like race conditions, memory protection, and system security itself. 

But what happens, if a process crashes inside the kernel? Because of the ”hard-wiring” of system processes and the resulting dependency of the monolithic approach, it is assumable that other processes will also crash, resulting in a system-wide halt.

I/O Communication

Monolithic kernels (and most of the first generation μ-kernels) run device drivers inside the kernel space. Hardware interrupts are directly handled by kernel processes.

The concept of so-called modules was introduced to achieve more independence and separation from the kernel. 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 adaption.

The μ-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 μ- kernel to the servers in userspace. If the hardware triggers an interrupt, the μ-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.

Extensibility and Portability

Adding new features to a monolithic system means recompilation of the whole kernel, often including the whole driver infrastructure. If you have a new memory management routine and want to implement it into a monolithic architecture, modification of other parts of the system could be needed. In the case of a μ-kernel, the services are isolated from each other through the message system. It is enough to reimplement the new memory manager. The processes which formerly used the other manager, do not notice the change. μ-kernels also show their flexibility in removing features. 

Linux Kernel

FreeRTOS

macOS Kernel