What the OS actually does
The operating system is a resource manager and an illusionist. It multiplexes one physical machine among many programs — each process believes it has its own CPU, memory, and devices. Three pillars drive every OS design: virtualization (CPU + memory), concurrency (threads, locks, races), and persistence (files that outlive processes).
The system-call boundary
User programs cannot touch hardware directly. They request kernel services through system calls — a controlled gateway into privileged code. libc wraps syscalls (printf → write, malloc → brk/mmap), but the actual privilege transition happens at the syscall instruction.
| User-space action | Typical syscall | Why kernel involvement |
|---|---|---|
| Read a file | read | Enforce permissions, page in data |
| Allocate memory | brk, mmap | Map virtual pages, track limits |
| Create a process | fork, execve | Duplicate address space, load binary |
| Send network data | sendto | Drive NIC, enforce socket policy |
Senior-level signal
When debugging "it works in my shell but not in systemd," check whether the service runs with different capabilities, file descriptors, or environment — not whether the code changed. strace -f -e trace=%network <cmd> quickly separates "my app is wrong" from "the kernel refused the syscall."
Where this goes next
Kernel vs User Mode & Traps explains how the CPU actually switches privilege levels when a syscall fires — the mechanism behind every row in the table above.
Further Reading
Hands-On Tasks (Optional)
Low-setup exercises on your local machine. No autograding — the goal is to build intuition, not pass a test.
- Count system calls in a simple command15m
Run `strace -c ls` and note which syscalls dominate (write, openat, getdents64, etc.). Repeat with `strace -c echo hello` — far fewer. The exercise builds intuition for what's kernel work vs. libc.