The OS Explained

September 10, 2026 • 7 min read

Table of Contents

What the OS is for
Kernel vs userspace: the two halves of the machine
Syscalls: the boundary you program against
What the OS manages
How the OS stays in control while barely running
The big picture

The CPU post ended with a loose thread: at machine level there is one executor running one instruction stream, yet your machine runs a browser, an editor, a music player, and a hundred background services at once. The computer overview named the piece that makes that possible in one word: the operating system. This post opens that word up. We will look at what the OS is for, the line between kernel and userspace, the system calls that form the boundary between them, the four things the OS manages, and the mechanism that lets it stay in control while barely running.

What the OS is for

An operating system¹ has two classic jobs, and every feature it offers serves one of them.

First, it is an extended machine: it hides the ugly hardware behind clean abstractions. Programs do not spin disk platters, program DMA controllers, or switch address spaces. They open files, read sockets, and allocate memory. The OS turns a machine of registers, interrupts, and sectors into something a programmer can reason about.

Second, it is a resource manager: it shares one machine among many claimants. There is one CPU (or a few cores), one memory, one disk, yet dozens of programs want all of them at once. The OS plays referee: who runs next, who gets how much memory, whose bytes land on disk, and what happens when two programs want the same thing. Orderly sharing, enforced fairly, is most of what an OS does all day.

Kernel vs userspace: the two halves of the machine

Not all code is trusted equally. Modern processors provide at least two privilege levels²: a privileged kernel mode (sometimes called supervisor mode) where any instruction is allowed, and a restricted user mode where dangerous operations trap. The kernel³ is the part of the OS running in kernel mode; everything else, your browser, your shell, the compiler, runs in user space⁴ under restriction.

The split exists for one reason: containment. A bug in a music player should kill the music player, not the machine. In user mode the CPU refuses to execute privileged instructions (disabling interrupts, reconfiguring the memory unit, talking to devices directly) and the memory hardware refuses to touch pages belonging to someone else. To do anything privileged, a user program must ask the kernel. That asking is the entire interface of the OS.

user mode                    kernel mode
─────────                    ───────────
browser, editor, games   →   kernel: processes, memory,
shell, compiler              files, devices, network
   │ restricted: no direct   │ privileged: full hardware
   │ hardware access         │ access, enforces isolation
   └────── ask via ──────────┘
           syscalls

A monolithic kernel (Linux) keeps most services inside the kernel for speed; a microkernel keeps the kernel tiny and pushes drivers and filesystems into user-space servers for isolation. The tradeoff is the oldest one in the book: fewer boundary crossings versus smaller blast radius. Either way, the boundary itself is what matters.

Syscalls: the boundary you program against

A system call⁵ is a controlled door from userspace into the kernel: the program traps into privileged mode, the kernel validates the request, performs it, and returns. If the CPU post was about the contract between software and silicon (the ISA), syscalls are the contract between programs and the OS.

A program that prints hello performs roughly this conversation on Linux:

write(1, "hello\n", 6)   → kernel copies 6 bytes to the terminal
exit(0)                  → kernel reclaims the process

You can watch it happen. Tracing a trivial program shows the boundary crossings explicitly:

$ strace ./hello
execve("./hello", ...) = 0
write(1, "hello\n", 6)  = 6
exit(0)                 = ?
+++ exited with 0 +++

A handful of calls cover most of what programs need: open, read, write, close for files; fork, exec, exit, wait for processes; mmap, brk for memory; socket, bind, connect for the network. C library functions like printf and malloc are not syscalls themselves. They are wrappers that eventually cross the boundary on your behalf, batching and buffering so that common operations avoid the crossing when they can.

What the OS manages

Four managers, one machine:

Processes. A process⁶ is a running program plus its state: code, memory, open files, and where it was interrupted. The OS creates processes, suspends them, resumes them, and cleans up after them, sustaining the illusion that each program owns the machine. How that illusion is built (process tables, fork and exec, isolation) is the next post’s subject.

Memory. Every process believes it owns a vast private address space; physically there is one RAM shared among all of them. Virtual memory⁷ maintains the fiction: per-process page tables translate virtual addresses to physical ones, the memory unit enforces the translation on every access, and the kernel pages data in and out of RAM and storage behind everyone’s back. That is also the machinery behind the malloc that the CPU post waved at: library bookkeeping on top of mmap and brk.

Files and storage. Disks hold blocks; humans want files with names, folders, and permissions. A file system⁸ bridges the gap: naming, directories, metadata, crash consistency, and access control. Your program opens /home/you/notes.txt; the OS resolves the path, checks permissions, finds the blocks, and journals the update so a power cut does not eat it.

Devices and I/O. Keyboards, screens, disks, and network cards each speak their own dialect. Device drivers translate: the kernel’s uniform request in, the device’s register pokes and interrupts out. The storage post showed the device side (cells, blocks, access patterns); the OS side is the queueing, caching, and scheduling that keeps slow devices from stalling fast CPUs.

How the OS stays in control while barely running

Here is the paradox: most of the time, the OS is not running. Your editor is. So how does the referee enforce anything?

Through interrupts⁹ and traps. Three events hand control back to the kernel whether the running program likes it or not: the program itself asks (a syscall trap), the hardware demands attention (a disk finished, a packet arrived, a key was pressed), or the timer fires. That last one is the keystone: a periodic timer interrupt wakes the kernel many times per second, giving it a chance to preempt the current program and run another. No cooperation required.

program A runs … timer fires … kernel runs … program B runs …
              ↑               ↑                  ↑
           interrupt      decides who        resumes where
           (forced)       runs next          it left off

Early systems tried cooperative sharing (each program yields voluntarily) and learned why it fails: one hung program freezes the machine. Modern systems are preemptive: the kernel takes the CPU back on its own schedule. Scheduling policies (who runs next, for how long, at what priority) deserve their own post, and they get one.

The big picture

A computer executes one instruction stream; an operating system turns that executor into a shared, protected, programmable machine. The kernel runs privileged and isolated in its own half of the world; programs live restricted in theirs and cross over only through syscalls; behind that narrow door the OS manages processes, memory, files, and devices; and timer-driven preemption guarantees the referee always gets the whistle back.

What a process actually is, how one is born, and what it costs to keep a hundred of them believing they are alone, is the next post’s subject.

Tagged:

Enjoyed this post? You can sponsor me and this site.