The previous chapter described the kernel's major responsibilities: managing execution, memory, files, devices, and networking.

That list leads to an architectural question:

How much of this functionality should run inside the privileged kernel?

A kernel architecture determines where operating-system services run and how they communicate.

The three commonly discussed designs are monolithic kernels, microkernels, and hybrid kernels. They provide many of the same visible services to applications, but they place different amounts of code behind the kernel's protection boundary.

Kernel code can access protected processor features and the kernel's memory. A bug in that code can potentially damage any part of the running system.

User-space code has fewer privileges and normally runs inside an isolated address space. If one user-space program crashes, the kernel can usually terminate it without losing the entire system.

Kernel architectures arrange operating-system components differently across this boundary.

A monolithic design puts most core services in kernel space. A microkernel moves many services to isolated user-space processes. A hybrid kernel combines ideas from both, usually keeping a substantial set of services in kernel space while using selected microkernel structures or user-space services.

These are design families rather than precise formulas. Real operating systems evolve over decades and rarely match a textbook diagram perfectly.

A monolithic kernel runs most core operating-system services in one privileged address space.

Process management, memory management, filesystems, networking, and many device drivers can call one another directly as kernel code.

The word monolithic can be misleading. It does not mean that the kernel is one enormous function or that its source code has no internal structure.

A well-designed monolithic kernel is divided into subsystems with carefully defined interfaces. The important feature is that those subsystems execute with the same kernel privilege and can communicate through ordinary function calls and shared kernel data.

Why direct communication helps performance

Suppose a filesystem needs data from a storage driver. In a monolithic kernel, the filesystem code can call the relevant kernel function directly, the same way any function in a program calls another.

The request does not need to be packaged as a message for a separate user-space service. The kernel also does not need to cross an additional protection boundary just to move between those components.

This makes communication efficient and allows tightly integrated subsystems. It is one reason monolithic kernels work well for general-purpose systems that perform large amounts of file, network, and device I/O.

The cost of a large privileged domain

The same shared environment creates risk.

Because a kernel component can access kernel memory, a bad pointer or memory-corruption bug in a device driver can overwrite data belonging to an unrelated subsystem. The result may be a security vulnerability, corrupted state, or a crash of the entire operating system.

The kernel's components are separated by software interfaces, but they are not strongly isolated from one another by hardware protection.

Testing, careful interface design, memory-safe implementation techniques, and hardware protection features can reduce this risk. They do not change the basic fact that a large amount of code runs with kernel privilege.

Linux is a monolithic kernel, but it is also modular.

Some Linux functionality is built directly into the kernel image. Other functionality can be added at runtime using loadable kernel modules. Device drivers, filesystems, and networking features are common examples.

Modules allow the kernel to support hardware and features that were not compiled into its core image. They can often be loaded when needed, so a system does not need every possible driver active from the start.

However, a kernel module is not an isolated user-space service.

Once loaded, module code runs in kernel space with kernel privilege. It can directly use kernel interfaces and, if it contains a serious bug, can crash or compromise the system.

This distinction is essential:

Modularity improves extensibility and maintainability. It does not by itself provide the fault isolation of a microkernel.

Observing Linux modules

Run the following command on Linux to list currently loaded modules:

A shortened result may look like:

To view information about a particular module, use:

For example:

lsmod shows loadable modules currently present in the running kernel. It does not show features compiled directly into the kernel, so it is not a complete list of kernel functionality.

A microkernel keeps the privileged kernel deliberately small.

The exact contents vary, but a microkernel usually retains only fundamental mechanisms such as low-level memory protection, execution scheduling, interrupt handling, and interprocess communication.

Services such as filesystems, networking, and device drivers can run as separate user-space processes, often called servers.

Running in user space does not make these servers ordinary applications. They are still operating-system components. User space describes the protection environment in which they execute.

Because these services occupy different address spaces, they cannot normally read or overwrite one another's memory. The microkernel controls which services may communicate and which resources they may access.

Communication through messages

Components in separate address spaces cannot use ordinary function calls with shared pointers in the same way as monolithic kernel components.

They communicate through interprocess communication, commonly abbreviated as IPC. A service packages a request into a message, the microkernel delivers it, and the receiving service sends back a result.

A simplified file request might follow this path:

Every hop passes through the microkernel, which is what the isolation costs. This is a responsibility map, not a universal microkernel path. Implementations can combine services, share memory safely, or optimize message delivery.

Why the isolation is useful

If a user-space driver crashes, the kernel and unrelated services may continue running. In some designs, a supervisor can restart the driver rather than rebooting the machine.

Isolation also supports the principle of least privilege. A storage driver can receive permission to access its device and selected memory regions without receiving unrestricted access to every kernel resource.

A small privileged core is easier to audit than a kernel containing many drivers and services. This property is especially valuable in systems that need strong security or safety assurance. The seL4 microkernel, for example, is well known for machine-checked proofs about important aspects of its implementation.

Restarting a failed service is not automatically simple. Other components may have requests in progress or state associated with that service. Microkernel systems need protocols for detecting failures and restoring consistent state.

Where the performance cost comes from

Moving a request between isolated services may require more boundary crossings, message transfers, and scheduling decisions than a direct call inside a monolithic kernel.

These operations consume CPU time and can disturb processor caches. A request that passes through several services can accumulate this overhead.

This does not mean that every microkernel is slow. Modern microkernels use highly optimized IPC, shared-memory techniques, and careful service design. The actual result depends on the implementation and workload.

The architectural trade-off is more precise:

Additional protection boundaries can improve isolation, but communication across those boundaries is generally more expensive than a direct call within one address space.

Microkernels are less common than Linux or Windows on general-purpose servers and personal computers, but they are important in several real environments.

QNX Neutrino is used in embedded and real-time systems, including automotive and industrial systems. Its service isolation and predictable behavior are useful when a failure can affect a physical device.

seL4 is used as a foundation for high-assurance embedded systems and security-sensitive projects. Its small verified kernel is attractive when developers must make strong claims about isolation.

MINIX 3 is primarily associated with education and operating-systems research. It also explores a reliability model in which user-space services and drivers can be monitored and restarted.

Microkernels are a natural fit when fault containment, a small trusted computing base, certification, or predictable real-time behavior matters more than maximizing the speed of every service interaction.

They are not limited to embedded devices, but replacing the ecosystem of a mature general-purpose kernel involves much more than designing a good microkernel. Hardware drivers, developer tools, application compatibility, and operational experience all influence adoption.

A hybrid kernel combines ideas associated with monolithic kernels and microkernels.

It may use message-oriented internal interfaces or microkernel-derived components while keeping filesystems, networking, drivers, or other major services in kernel space for performance.

The term hybrid does not describe one standard layout. It is used for systems that deliberately mix architectural approaches.

The Windows NT family is commonly classified as hybrid. It has a layered internal design and several user-space system processes, but its executive, kernel, and many drivers run with kernel privilege.

Apple's XNU kernel, used by macOS and iOS, is also commonly described as hybrid. It combines Mach-derived mechanisms with BSD operating-system services and Apple's driver framework, with substantial functionality executing in kernel space.

These systems keep common operations close together in the privileged kernel while using modular layers and selected user-space services. Their practical performance and isolation depend on exactly where each component runs, not simply on the hybrid label.

A detailed comparison of Linux, Windows, and macOS appears later in this module.

The central difference is the placement of services and protection boundaries.

Read the table as one axis rather than three separate designs. At the monolithic end there are more services in kernel space, more direct calls, and a larger privileged failure domain. At the microkernel end there are more user-space services, more message passing, and a smaller privileged core. Hybrid designs sit between them and mix the placements.

This is not a ranking from worst to best. A monolithic kernel still isolates user processes from one another, and a microkernel service can still contain bugs. A carefully implemented monolithic system may be more reliable than a poorly implemented microkernel system.

Architecture determines where failures can spread and how components communicate. Implementation quality, driver support, workload, and operational requirements determine how well the resulting system works.

A buggy device driver makes the architectural distinction concrete.

In a monolithic kernel, the driver commonly shares the kernel's address space. An invalid memory write can corrupt unrelated kernel data and crash the whole system.

In a microkernel, a user-space driver normally has a separate address space. The driver process may crash, and operations using that device may fail, but the microkernel can remain intact. The system may be able to restart the driver.

In a hybrid kernel, the outcome depends on where that particular driver runs. A kernel-space driver has a failure domain similar to a monolithic driver, while a user-space driver receives stronger isolation.

This example captures the main architectural choice: placing code in kernel space makes interaction efficient, but it also places that code inside the system's most trusted failure domain.

A kernel architecture determines which operating-system services run with kernel privilege and how those services communicate.

Monolithic kernels keep most services together in kernel space, enabling efficient direct communication but creating a larger failure domain. Microkernels move many services into isolated user-space processes, improving fault containment at the cost of additional communication across protection boundaries. Hybrid kernels deliberately combine elements of both designs.

Linux is monolithic but modular: loadable modules improve extensibility, yet they still execute with kernel privilege. Microkernels such as QNX and seL4 are especially useful in embedded, real-time, and high-assurance systems.

The essential mental model is:

Kernel architecture is a decision about where to place trust, protection boundaries, and communication costs.