Kernel architectures and types of OS

Why it matters

Kernel architecture decides what a bug can destroy. A faulty network driver on a Linux host takes the whole machine down; the same fault in QNX restarts one process while the car's dashboard keeps running. That is why cars and aircraft keep Linux out of the critical path, and why Linux wins almost everywhere else. The OS families matter for the same reason: a GPU cluster's job queue is a batch system, a pacemaker is hard real-time. Interviewers ask "monolithic versus microkernel" to test exactly this.

The idea

The kernel is the code that runs with full hardware privilege, and the architectural question is how much goes inside it. Every design keeps the scheduler and low-level memory management there. The argument is about the rest: file systems, the network stack, and above all device drivers, the largest and least tested code in any OS.

Three designs

A monolithic kernel puts all of it in one privileged address space: Linux, the BSDs, classic Unix. A file read passes from the VFS to ext4 to the block layer to the NVMe driver as plain function calls, with no crossings, which is fast. The cost is that any component can corrupt any other: a null pointer in a driver is a kernel panic. Loadable kernel modules let drivers be built separately and inserted with modprobe, but a loaded module has the kernel's full privilege: modularity is packaging, not protection.

A microkernel keeps only scheduling, address spaces and inter-process communication privileged. Drivers, file systems and the network stack run as user-space processes called servers, and a read becomes messages: application to file server, file server to disk driver, and back. MINIX 3, QNX, and seL4, about 10,000 lines and formally proven free of implementation bugs, are the working examples. A crashed driver is a crashed process that a supervisor restarts.

A hybrid kernel keeps the microkernel's structure but runs most servers in kernel mode for speed. Windows NT's executive and most drivers share one address space, which is why a bad driver still produces a blue screen. Apple's XNU joins the Mach microkernel to a BSD layer and I/O Kit drivers in one address space, though recent macOS moves USB and audio drivers into user-space DriverKit processes.

Linux borrowing microkernel ideas

1. 1

   User-space file systems

   FUSE routes file operations to a process, so sshfs and s3fs crash harmlessly, at the cost of extra copies and crossings.
2. 2

   User-space device access

   UIO and VFIO map a device's registers and interrupts into a process, which is how DPDK drives NICs with no kernel code.
3. 3

   Verified or safer kernel code

   eBPF programs run in the kernel only after a verifier proves they terminate and touch only permitted memory, and Rust is accepted for new drivers so memory-safety bugs fail at compile time.

The families of operating system

The families describe what an OS is optimised for, not how its kernel is built. A batch system runs jobs without interaction and maximises throughput: alive as Slurm and Kubernetes job queues. A time-sharing system switches rapidly between processes so each user sees quick responses; every desktop and server OS is one. A real-time system guarantees deadlines: hard real-time treats a missed deadline as failure, so anti-lock brakes and flight controllers run QNX, VxWorks or bare-metal RTOSes with interrupt latency bounded in microseconds, while soft real-time, such as video playback on Linux with SCHED_FIFO, tolerates rare misses. The Real-time scheduling lesson covers the algorithms. An embedded system runs on a fixed device with tight memory and power: FreeRTOS and Zephyr fit in tens of kilobytes. A mobile OS is a time-sharing kernel with power management and sandboxing on top: Android is Linux with Binder IPC, iOS is XNU. A distributed system presents many machines as one; Kubernetes plays that role today, placing processes across a cluster as a kernel places them across cores.

Trade-offs

Monolithic design buys speed and ease of development with a wide blast radius; after thirty years Linux still ships driver panics. Microkernels buy fault containment and provability with more crossings, more engineering per driver and a smaller hardware ecosystem, so they dominate only where failure is unacceptable. Hybrids inherit a little of each and the monolith's failure mode. A hard real-time kernel likewise gives up throughput for bounded latency, and a batch system gives up responsiveness for utilisation.

In an interview

Answer with isolation, cost and an example in one breath. "Linux is monolithic, so a driver bug is a kernel panic; QNX is a microkernel, so the same bug restarts one process, which is why cars run QNX and servers run Linux." Then the nuance: "The crossing cost that sank early microkernels is under a microsecond on seL4, so the remaining argument is the driver ecosystem."