Learning outcomes
- Explain the differences between monolithic kernels and microkernels and their design trade‑offs.
Unit 1 · Introduction & OS Structure
Lecture 9: Kernel designs: monolithic vs microkernel
Lecture Notes
Main content
Unit 1 — Introduction & OS Structure
Lecture 9: Kernel Designs — Monolithic vs Microkernel (Reentrant Kernel Included)
Learning Outcome
Compare monolithic and microkernel designs, identify where OS services (drivers, file system, networking) reside in each model, and explain key trade-offs. Explain the reentrant kernel concept and why it is important in modern systems.
1) Reentrant Kernel
A kernel is reentrant if multiple processes/threads can execute inside the kernel at the same time without corrupting shared kernel data structures. This is essential on modern systems due to interrupts, preemption, and multi-core execution.
Why do we need reentrancy?
- Interrupts: hardware can interrupt kernel execution.
- Multi-core: two CPUs may enter the kernel simultaneously (e.g., allocating memory at the same time).
- Preemption: higher-priority tasks can interrupt lower-priority kernel activity.
How is reentrancy achieved?
- Locking: mutexes/spinlocks to protect shared kernel structures.
- Atomic operations: hardware instructions that execute indivisibly.
- Per-CPU variables: CPU-local data to reduce contention and avoid conflicts.
Important clarification
- Reentrancy is a property of a kernel, not a separate architecture.
- A system can be monolithic or microkernel and still be reentrant.
- Reentrancy depends on correct synchronization (covered in later units).
2) Why kernel design matters
The kernel is the trusted core of the OS. Kernel design decisions influence: performance (system-call speed, I/O efficiency), stability (impact of driver/service failures), and maintainability (how easily the OS can evolve). Two classic designs are monolithic kernels and microkernels.
3) Monolithic Kernel
In a monolithic kernel, most operating-system services execute in kernel space. Along with core functions (scheduling, memory management), services like file systems, networking, and many device drivers are typically part of the kernel.
Main idea
- Large kernel containing many OS services.
- Subsystems interact using direct kernel function calls.
- Lower overhead for internal interactions.
Strengths
- High performance due to direct calls and shared in-kernel data structures.
- Efficient I/O path (drivers and core subsystems are close to hardware).
Limitations
- Large trusted code base (bigger attack surface).
- A buggy kernel-mode driver can crash the entire OS.
4) Microkernel
A microkernel keeps the kernel minimal and moves many OS services into user space as separate processes (servers). The microkernel focuses on the most fundamental mechanisms.
What stays in the microkernel
- Basic IPC (message passing / communication support).
- Basic scheduling.
- Basic low-level mechanisms needed for safe operation (OS-dependent).
What moves to user-space servers
- File-system services
- Device drivers
- Networking services
- Other OS services as user-mode processes
Strengths
- Fault isolation: driver/server failure can be contained.
- Modularity: services can be restarted/updated more cleanly.
- Smaller trusted kernel for security and verification.
Commonly cited examples:
- Microkernel families: MINIX, QNX, L4
- Modern kernels often include microkernel influences (hybrid designs).
5) Monolithic vs Microkernel (Architecture Diagram)
6) Why microkernels can be slower
In a microkernel OS, when a user process needs a service (like file I/O), it may communicate with a user-space server. That communication typically involves IPC message passing, possible copying of data across address spaces, and context switches between processes. This adds overhead compared to direct in-kernel calls.
Exam line:
Microkernel modularity is achieved using IPC, but IPC + context switching can reduce performance.
7) Comparison Matrix
| Feature | Monolithic Kernel | Microkernel |
|---|---|---|
| Philosophy | "All-in-one" efficiency. | "Minimal core" + modular services. |
| Kernel Size | Large; includes many services (drivers, file system, etc.). | Small; keeps only core mechanisms. |
| Stability | Lower; kernel-mode bug can crash the system. | Higher; service/driver faults can be isolated in user space. |
| Performance | High (direct calls; lower overhead). | Potentially lower (IPC + switching overhead). |
| Examples | Linux, UNIX (classic view). | MINIX, QNX, L4. |
8) Modular / Hybrid kernels (practical approach)
Many real operating systems mix ideas. A common approach is to keep a core kernel and add features dynamically using loadable kernel modules (drivers, file systems, optional subsystems). This improves flexibility while keeping kernel-level performance for core paths.
What modules enable
- Add/remove drivers and features without rebuilding the whole kernel.
- Keep the core kernel focused and smaller than a fully static monolith.
- Practical balance of performance and maintainability.
What remains essential
- Core scheduling and memory management
- Interrupt handling and system-call interface
- Kernel synchronization to support safe concurrency (reentrancy)
9) Quick Self-Check
- Where do device drivers typically run in monolithic and microkernel designs?
- What is the main reason microkernels can be slower?
- Define a reentrant kernel in one line.
- Name any two mechanisms used to make a kernel reentrant.
- What is a loadable kernel module and why is it useful?
Worked Example
Worked Example: “A buggy network driver crashes” — what happens?
A) Monolithic kernel case
- The network driver runs in kernel space.
- If the driver dereferences a bad pointer, it can corrupt kernel memory.
- Result: the OS may crash (system-wide failure).
“Bad driver can crash the whole OS” (stability risk). :contentReference[oaicite:28]{index=28}
B) Microkernel case
- The network driver runs as a user-space server.
- If it crashes, the kernel is still protected (smaller trusted core).
- Result: the driver/service can be restarted; system continues with reduced functionality temporarily.
Microkernel keeps most services in user mode; QNX example shows this structure. :contentReference[oaicite:29]{index=29}
Trade-off reminder:
Microkernel improves failure isolation, but extra IPC and context switching can add overhead. :contentReference[oaicite:30]{index=30}
One-Page Summary
One-Page Summary — Monolithic vs Microkernel (with Reentrant Kernels)
- Monolithic kernel: most OS services (device drivers, file system, networking, etc.) run in kernel space → typically fast due to direct kernel-to-kernel calls, but a faulty kernel-mode component can cause system-wide failure.
- Microkernel: kernel is kept minimal; many services run as user-space servers → better modularity and fault isolation, but performance may decrease due to IPC/message-passing and extra context switches.
- Microkernel examples (book): Darwin includes the Mach microkernel; QNX follows a microkernel approach where most services run outside the kernel.
- Why microkernels can be slower: communication may require copying messages between address spaces and switching between processes/servers → adds overhead compared to direct kernel calls.
- Hybrid / modular reality: real systems often blend ideas: performance needs pushed some designs (e.g., Windows NT history) toward more kernel integration, while modern OS frequently use loadable kernel modules (core kernel + dynamically loadable drivers/file systems).
- Reentrant kernel (Unit-1 add-on): a kernel is reentrant if multiple threads/processes can safely execute inside kernel code at the same time without corrupting shared kernel data. Reentrancy is achieved using locks, atomic operations, and sometimes per-CPU data. It is a property of a kernel (monolithic or microkernel), not a separate architecture.
- Most important exam takeaway: Monolithic vs microkernel is mainly a trade-off between performance and modularity/fault isolation, and reentrancy is about safe concurrent kernel execution (important for interrupts, preemption, and multi-core CPUs).