Architecture of Linux Kernels

July 26th, 2009  |  Published in Amit Sahrawat

The Linux operating system is Monolithic. Generally an operating system can be made to work in 3 flavors – real time executive, monolithic and microkernel. All three can be differentiated on the basis of how the OS makes use of hardware for protection. 

1. Real time Executive

Real time executives were meant for MMU (Memory management Unit)-less processors. On these operating systems, the entire address space is flat or linear with no memory protection between the kernel and the user space applications.


Architecture of Real time Executive Kernel

The architecture is as shown in the figure.

These operating systems have small memory and size footprint as both the OS and applications are bundled into a single image. They are termed as real-time because there is no overhead of system calls, message passing or copying of data. Since, there is no protection from OS, so all the applications (software) running on the system should be fail safe. Adding a new application to the system is not an easy task, because it needs to be tested thoroughly lest it would bring down the whole system. Also, for inserting applications and kernel modules dynamically the complete system needs to be brought down. Most of the commercial and proprietary RTOS fall under this category.

 The traditional embedded system model was based on having tightly controlled software running on the boards; the cost of memory and storage space further restricted the amount of software that could be run on the system. Reliability on real-time executives using the flat memory model was achieved by a rigorous testing process. However, as the prices of memory and flash dropped and computing power became cheaper, embedded systems started having more and more software on their systems. And lots of this software was not just system software (such as drivers or networking stack) but were applications. Thus software too started becoming the differentiating factor in selling the embedded systems, which were traditionally judged mainly by the hardware capabilities. Real-time executives were not suited for large-scale software integration; hence alternative models were seriously looked at with the aim of getting more software to run on the system. Two such models are the monolithic and the microkernel models for operating systems. These are suited for processors having MMU. Note that if the processor itself lacks a MMU, then the OS has no alternative but to provide the flat addressing model. (The Linux derivative uClinux that runs on the MMU-less processors provides flat address space. 

2. Monolithic Kernel

Monolithic kernels have a distinction between the user and kernel space. When software runs in the user space normally it cannot access the system hardware nor can it execute privileged instructions. Using special entry points (provided by hardware), an application can enter the kernel mode from user space. The user space programs operate on a virtual address so that they cannot corrupt another application’s or the kernel’s memory. However, the kernel components share the same address space, so a badly written driver or module can cause the system to crash.


Architecture of Monolithic Kernel

Monolithic kernels can support a large application software base. Any fault in the application will cause only that application to misbehave without causing any system crash. Also applications can be added to a live system without bringing down the system. Most of the UNIX Operating Systems are monolithic.


The microkernel makes use of a small OS that provides the very basic service (scheduling, interrupt handling, message passing) and the rest of the kernel (file system, device drivers, networking stack) runs as applications. On the usage of MMU, the real-time kernels form one extreme with no usage of MMU whereas the microkernels are placed on the other end by providing kernel subsystems with individual address space. The key to the microkernel is to come up with well-defined APIs for communication with the OS as well as robust message-passing schemes.

Architecture of Microkernel

Architecture of Microkernel

Microkernels require robust message-passing schemes. Only if the message passing is proper are real-time and modularity ensured.

NOTE: There has been some confusion regarding the monolithic architecture of Linux with the introduction of dynamically loadable kernel modules. Dynamically loadable kernel modules are pieces of kernel code that are not linked (included) directly in the kernel. One compiles them separately, and can insert them into and remove them from the running kernel at almost any time.

Loadable kernel modules have a separate storage and are brought into memory only when needed, thus saving memory. The point to be noted is that increasing modularization of the kernel does not make it any less monolithic because the kernel interacts with the drivers using direct function calls instead of message passing.


Get articles in your inbox.

Enter your email address:

Join Us

Twitter Chatter