A monolithic kernel includes all OS services—file systems, drivers, networking, memory management—in privileged kernel space. Components communicate via direct function calls, which is fast but means a bug in any component can crash the system. Linux and FreeBSD are monolithic.

A microkernel keeps only essential services (IPC, scheduling, basic memory management) in kernel space, running everything else as unprivileged user-space processes that communicate via message passing. This provides strong fault isolation—a file system crash doesn't crash the kernel—but introduces IPC overhead. Examples include MINIX and seL4.

Most production systems use hybrid designs that try to get the best of both worlds by keeping performance-critical services in the kernel while moving less critical ones to user space.

Linux chose monolithic architecture primarily for performance. Direct function calls between kernel components have near-zero overhead compared to message passing across address spaces. For server workloads handling millions of syscalls per second, this matters enormously.

Linux also evolved practical solutions to monolithic kernel weaknesses: loadable kernel modules allow adding/removing drivers without rebooting; robust kernel debugging tools (KASAN, KCSAN, lockdep) catch many bugs before release; and decades of performance optimization have refined the design. The result is a kernel that's both extremely fast and surprisingly stable despite its size.

A kernel module is code that can be loaded into the kernel at runtime to extend functionality without rebooting. Device drivers are the most common example—GPU drivers, network drivers, and filesystem drivers are often modules.

Modules solve a key monolithic kernel problem: the need to update drivers or add support for new hardware without disrupting running services. When you run modprobe nvidia, the NVIDIA driver loads into the running kernel and integrates seamlessly with the rest of the system. When you no longer need it, modprobe -r unloads it. This modularity without sacrificing the performance benefits of monolithic design is a key reason Linux dominates in servers and embedded systems.

IPC (Inter-Process Communication) is the fundamental mechanism for communication in microkernel systems. Since services like file systems and network stacks run in user space, applications must send messages to request their services. The kernel handles message delivery between address spaces.

Common IPC mechanisms include: message queues (ordered bytes), channels/ports (typed message delivery), shared memory regions (for bulk data transfer), and signals (asynchronous notifications). In seL4, IPC is capability-based: you can only send messages to services you have been granted access to. This enforces the principle of least privilege at the kernel level.

XNU (X is Not Unix) combines three components: the Mach microkernel provides core abstractions—threads, tasks, ports, and IPC—without which no OS can function. On top of Mach sits the BSD layer, which provides the traditional Unix personality: processes, file systems (APFS, HFS+), the network stack (TCP/IP), and POSIX compliance. Finally, the I/O Kit provides a C++ driver framework for device drivers.

The advantage is separation of concerns: Mach handles low-level resource management, BSD handles compatibility and high-level services, and the I/O Kit provides a modern driver model. The downside is complexity—these components interact in subtle ways, and a bug in one layer can cascade. Apple has invested heavily in making this work, which is why macOS manages to be both relatively stable (thanks to memory protection from Mach) and performant (thanks to optimized BSD and I/O Kit code).

In a microkernel, services like file systems and network stacks run as user-space processes (servers) communicating via IPC. This is fundamentally different from Linux kernel modules, which run in kernel space with the same privilege as the core kernel. A kernel module has direct access to all kernel data structures, can handle interrupts, and can crash the kernel if buggy. A user-space server crashes in isolation—it does not corrupt kernel memory, and can be restarted without rebooting. The tradeoff is IPC overhead: every file system operation in a microkernel requires a message to cross to the file system server and a response to cross back. This adds microseconds of latency per operation. For workloads where latency is critical, this overhead matters. For reliability-focused workloads, the isolation benefit outweighs the performance cost.

seL4 is the most formally verified kernel in the world—its correctness has been proven mathematically using theorem provers (Isabelle/HOL). The proof covers functional correctness (the implementation matches the specification), security enforcement (capability model is enforced), and binary equivalence (the binary matches the source). The practical benefit: a seL4-based system can provide mathematical guarantees that certain classes of bugs (memory safety violations, privilege escalation, buffer overflows in kernel code) simply cannot occur. For security-critical systems (medical devices, aerospace, automotive), this formal guarantee is valuable. However, formal verification does not guarantee correctness of application code running on seL4, nor does it protect against hardware bugs. seL4's proof is also only as good as the specification—if the spec is wrong, the proof is of the wrong thing.

Zircon is the kernel at the heart of Google's Fuchsia OS. It is a small kernel (approximately 100K lines) that provides only fundamental operations: threads, virtual memory, IPC via channels, and I/O. Unlike Linux's monolithic design, Zircon intentionally keeps the kernel small and moves as much as possible into user-space components called "components." These components communicate via capability-based IPC (handles that grant access rights). Zircon has no traditional Unix personality—no POSIX compatibility built-in, though some can be implemented in user space. This design supports Fuchsia's security model where each component has only the capabilities it needs. The kernel handles device driver loading via a user-space driver framework (FIDL). Fuchsia's architecture shows that modern kernels can abandon Unix compatibility as a design goal, enabling cleaner security boundaries.

A real-time kernel must provide deterministic response times—the time between an event (interrupt) and the handling of that event must be bounded and predictable, not just fast on average. Hard real-time means missing a deadline is catastrophic (airbag systems); soft real-time means missing a deadline causes degraded quality (audio streaming). A real-time kernel achieves this by having minimal interrupt latency (no extended critical sections where interrupts are disabled), priority-based preemption (high-priority tasks preempt lower-priority ones immediately), and no unbounded blocking operations. Linux can be configured as a real-time kernel (PREEMPT_RT patch) to reduce maximum preemption latency to microseconds. Microkernels like QNX are designed from the ground up for real-time behavior. The key metric is worst-case latency, not average latency.

Windows NT's architecture has three layers: the Hardware Abstraction Layer (HAL) which isolates the kernel from hardware differences, the NT Executive (kernel-mode services) which provides object manager, memory manager, process/thread management, I/O manager, and security, and the Win32 subsystem which provides the user-mode API. The HAL means the kernel itself is not tied to x86 specifics—different hardware platforms can share the same kernel code with different HALs. The Executive runs as a unified kernel (monolithic) but separates functionality into subsystems. Linux, by contrast, has the kernel proper (scheduler, memory management) with device drivers as loadable modules in the same address space. Windows driver model (WDM/WDF) runs kernel-mode drivers with defined entry points and IRP (I/O request packet) dispatch. The key architectural difference: Linux exposes a Unix/POSIX interface at the kernel level; Windows Executive exposes a different (internal) object model, with the Win32 API as a user-mode library.

A system call is the boundary between user space and kernel space—it is how user programs request services from the kernel. Unlike a regular function call (which stays within the same address space), a syscall transitions the CPU to a higher privilege level (ring 0 on x86) where kernel code executes. This transition involves a mode switch: from user mode (limited access) to kernel mode (full access to all memory and hardware). The transition is expensive—hundreds of cycles for the mode switch itself, plus the overhead of the kernel's internal processing. Optimizations like vDSO (virtual dynamic shared object) allow some syscalls (like `gettimeofday`) to be handled in user space without a mode switch. The syscall interface is also the primary attack surface for kernel exploits—every syscall handler must validate its inputs carefully because hostile user code is calling it.

Kernel preemption means that while the kernel is executing, it can be interrupted and a higher-priority process can take the CPU. Without preemption, once kernel code starts running, it runs to completion (or until it explicitly yields), even if a higher-priority process becomes runnable. This causes latency spikes. The PREEMPT_RT patch adds fine-grained preemption to Linux by making more kernel code preemptible: converting spinlocks to sleeping locks where safe, adding preemptible regions in scheduler and interrupt handling code, and enabling RCU (read-copy-update) to be preemptible. With PREEMPT_RT, maximum preemption latency drops from milliseconds to microseconds, making Linux suitable for soft real-time workloads. The tradeoff is slightly lower throughput for some workloads due to increased context-switch overhead, and more complexity in the kernel code due to the need to handle being preempted at arbitrary points.

An oops (also called a kernel bug) is a recoverable error—the kernel detected an illegal condition (like a null pointer dereference or illegal instruction) but can continue. After an oops, the kernel prints debug information and either kills the offending process or, if the oops is in interrupt context or at a dangerous point, calls `panic()`. A panic is unrecoverable—the kernel halts, prints diagnostic information, and the system is dead. An oops in user-space context (a process triggering a kernel bug) typically kills only that process and the kernel survives. An oops in atomic context (inside an ISR, or holding a spinlock) cannot be recovered because the kernel cannot safely schedule. With `CONFIG_PANIC_ON_OOPS`, you can make the kernel panic on any oops, treating all bugs as fatal. This is appropriate for hard real-time systems where incorrect operation is worse than crashing.

A pure monolithic kernel (like early UNIX or some embedded kernels) includes all functionality at compile time—device drivers, filesystems, and network stack are all part of the kernel image and cannot be changed without recompiling. Linux is modular: device drivers can be compiled as loadable kernel modules (`.ko` files) that can be loaded and unloaded at runtime without rebooting. This provides flexibility—new drivers can be added without kernel recompilation, and drivers for hardware not present at compile time can be loaded later. The tradeoff is that loadable modules run in the same kernel address space as the core kernel, so a buggy module can crash the system just like built-in code. Module signing and Secure Boot validation provide some security, but modules remain a kernel-mode attack surface. The module system is one reason Linux can run on everything from embedded devices to supercomputers.

The kernel-to-user transition occurs when a user-space process makes a syscall and the kernel completes the request, returning control to user space. The kernel must: (1) switch CPU privilege levels from kernel to user mode (via `iret` on x86 after restoring user stack pointer and instruction pointer); (2) load the user stack pointer with the user-space stack; (3) load the instruction pointer with the return address from when the syscall was made; (4) set up the correct CPU flags for user mode. If the kernel corrupts any of these during the transition, the user process will run with corrupted state—potentially reading wrong memory, jumping to invalid addresses, or running with elevated privileges. The transition must also ensure that kernel addresses (kernel memory layout) are not visible to user space—address space layout randomization (KASLR) ensures user space cannot predict kernel addresses to exploit them.

In a microkernel, every operation that requires kernel-level privileges is delivered via IPC to a user-space server. This means the kernel can enforce capability-based security: a process can only send messages to services it has been explicitly granted access to. The kernel's IPC mechanism itself is the only privileged operation. A file read would go: client → kernel (via IPC) → filesystem server (user space) → kernel → disk driver server → kernel → client. Each hop is validated. This design limits the blast radius of a compromise—if the filesystem server is breached, the attacker only has the filesystem server's capabilities, not full system privileges. In a monolithic kernel, a compromised driver has full kernel privilege. The cost is IPC overhead and the complexity of the overall system, since multiple servers must communicate to service even simple requests.

Linux's scheduler uses a class-based architecture where the main Completely Fair Scheduler (CFS) handles normal processes, but other scheduler classes can be registered for special workloads. Each class has its own run queue and scheduling policy. The CFS is the default for normal time-sharing processes. Real-time scheduler classes (SCHED_FIFO, SCHED_RR) can preempt CFS. There are also scheduler classes for idle processes (stop/sleep), background tasks, and batch workloads. The scheduling decision walks the scheduler class hierarchy in priority order, finding the highest priority class with a runnable task. This modular design means you can add new scheduling policies (like Google's BBR scheduling for networking, or the budget fair queueing for interactive workloads) without modifying the core scheduler. The priority inheritance protocol (PI) futex also plugs into this architecture for mutex priority inheritance.

VFS is the abstraction layer that sits between user-space system calls (read, write, open, close) and the actual filesystem implementations (ext4, XFS, Btrfs, NTFS, etc.). VFS defines the standard interface every filesystem must implement: `struct inode_operations`, `struct file_operations`, `struct super_block`. When a process opens a file, VFS determines which filesystem owns that path, looks up the filesystem's inode, and from then on routes operations through the filesystem's function pointers. This is how Linux can mount ext4, XFS, and tmpfs simultaneously—all present the same interface to user space. The VFS also handles network filesystems (NFS, CIFS/SMB), FUSE (userspace filesystems), and virtual filesystems like /proc. VFS caching (dentry cache, inode cache) makes lookups fast. This abstraction is why the same system call API works for all filesystems without application changes.

The MMU is the hardware unit that translates virtual addresses to physical addresses using page tables. The TLB is a cache of recent virtual-to-physical translations that the MMU checks before doing a full page table walk. A TLB miss costs tens of cycles (walking the page table in memory); a TLB hit costs a single cycle. Kernel and user processes both go through the MMU for address translation. When the kernel switches address spaces (via `switch_mm` on x86), the TLB may need to be flushed or tagged—the kernel uses PCIDs (process context identifiers) to tag TLB entries per process so that switching doesn't require a full TLB flush. For large kernel address spaces with sparse mappings, TLB pressure is significant. Some architectures (like x86 with PTI enabled for meltdown mitigation) use separate kernel and user page tables, doubling TLB pressure. Huge pages reduce TLB pressure by covering more virtual memory per entry.

High-reliability systems (medical devices, aerospace control systems, automotive safety systems) choose microkernels for fault isolation, not performance. When a filesystem server crashes in a microkernel, it can be restarted and the system continues operating. When a driver crashes in a monolithic kernel, it typically crashes the entire kernel. For safety-critical systems, a crash that can be contained and recovered is better than a crash that stops the entire system. Automotive systems running AUTOSAR or POSIX-based infotainment use QNX (microkernel) precisely because the separation allows a media player crash to be isolated while the real-time engine control continues. The performance overhead of microkernel IPC (microseconds) is negligible compared to the disk I/O and network latency that are the dominant latencies in most applications. Reliability and maintainability outweigh microsecond-level overhead in these domains.