OS Structure Overview

An operating system is not one giant program. It's a collection of parts, each responsible for a different job, arranged in a deliberate way. "OS structure" is simply the question of how those parts are organized: which pieces are trusted with full control of the hardware, which pieces are kept at arm's length, and how they talk to each other. Different operating systems answer that question differently, and those answers are the architectures you'll meet in this topic.

Before you can talk about architectures, you need one idea: memory and privileges are split into two worlds. The kernel is the core of the OS, and it runs in kernel space where it can touch any piece of hardware and any byte of memory. Your programs — the browser, the code editor, the music player — run in user space, where the hardware physically refuses to let them do anything dangerous.

The CPU itself enforces the split. It keeps a mode bit that says which world it is currently in. In kernel mode every instruction is allowed. In user mode the privileged instructions — halt the CPU, change the memory map, talk directly to a disk controller — are simply blocked. When a program needs one of those things done, it has to ask the kernel through a system call.

Stacked up, a typical system looks like this — read it from the top down, from what you click to the silicon underneath:

Whatever the architecture, the same set of jobs has to get done somewhere. In a monolithic kernel they all live inside the kernel; in a microkernel most of them are pushed out to user space. Either way, this is the work:

It's tempting to think this is an academic question. It isn't. Where a piece of code lives decides what happens when that code has a bug. A printer driver running inside the kernel that dereferences a bad pointer can take the entire machine down — that's the classic Windows blue screen or Linux kernel panic. The same driver running as an ordinary user-space program would just crash itself, and the OS could restart it while everything else kept running.

The catch is cost. Two pieces of code inside the kernel talk to each other with a plain function call, which takes a handful of nanoseconds. Two pieces separated across the user/kernel border have to exchange messages, and every message means saving state, switching privilege levels, and switching back. Do that millions of times a second and the difference becomes very real.

Here are the five structures you'll be asked about, roughly in the order they appeared historically. Each one gets its own lesson in this topic — this is the map before the detail.

One more design turns up occasionally in interviews: the exokernel. It takes minimalism even further than a microkernel by refusing to provide abstractions at all — it just safely divides up the hardware and lets each application build the abstractions it wants. It's mostly a research idea, but it shows that the spectrum doesn't end at the microkernel.

The fastest way to keep these straight is to compare them on the two things that actually differ: how much code sits in kernel space, and what happens when part of the OS fails.