// the one-minute version
An OS shows two faces. To you it offers services — run programs, open files, talk to the network. To programs it offers system calls, the controlled doorways into the kernel. This chapter covers those services, exactly how a system call crosses into the kernel and back, the six families of calls, the system programs wrapped around the kernel, and the handful of ways a kernel is structured — monolithic, layered, microkernel, modular, hybrid.
Chapter 1 said the OS sits between apps and hardware. Chapter 2 opens the box: what services does it actually offer, how do programs reach them, and how is the thing itself built inside?
01 What services an OS provides
Some services help the user: program execution, I/O operations, file manipulation, communication between processes, and error detection. Others keep the system efficient and safe: resource allocation, accounting (who used what), and protection and security. The first group makes the machine usable; the second makes it shareable.
User-facing
Program execution, I/O, file manipulation, communication, error detection.
System-facing
Resource allocation, accounting, protection and security.
02 The two interfaces: shell and system calls
People reach the OS through a user interface — a command-line shell or a GUI. Programs reach it through system calls, the only legitimate way for ordinary code to ask the kernel for privileged work. Most programmers never write raw system calls; they call a friendly library function (like fopen) and the library makes the real call (open) underneath.
printf is an API; it eventually issues the write system call. Coding to the API keeps your program portable across OSes that implement the calls differently.03 How a system call actually works
Behind the convenient function is a precise hardware dance. The program puts the call's number and arguments in agreed registers (or on the stack), then executes a special trap instruction (syscall on x86-64). That instruction switches the CPU to kernel mode and jumps to a fixed entry point. The kernel reads the call number, looks it up in the system-call table, validates the arguments, runs the service, places the result in a register, and executes a return-from-trap that switches back to user mode. The program resumes as if it had called an ordinary function — but the CPU briefly held the keys to the whole machine.
04 Types of system calls
Six families cover almost everything:
| Category | Examples | Purpose |
|---|---|---|
| Process control | fork, exec, exit, wait | start, stop, coordinate programs |
| File management | open, read, write, close | work with files and directories |
| Device management | ioctl, read, write, release | get and use hardware devices |
| Information | getpid, time, sysinfo | read/set system data |
| Communication | pipe, socket, send, recv, shmget | move data between processes |
| Protection | chmod, umask, chown | control who can access what |
05 System programs
Around the kernel sits a layer of system programs (utilities): file managers, editors, compilers, shells, status tools, background services. They aren't the kernel, but to most users they are "the operating system" because they're what you touch. The shell is the classic example — a user-mode program that reads your commands and uses system calls to carry them out.
06 How the kernel itself is structured
There's no single right way to build a kernel. Five designs trade simplicity, speed, and reliability:
Monolithic
Everything — scheduling, memory, file systems, drivers — in one kernel address space. Fast (no crossing costs) but huge and fragile: one bad driver crashes all of it. Classic UNIX.
Layered
Stacked layers, each using only the one below. Clean and easy to reason about, but rigid and sometimes slow as requests pass through many layers.
Microkernel
Keep the kernel tiny — scheduling, basic memory, message passing. Push file systems and drivers to user-space servers. Robust and modular, but message passing adds overhead.
Modular
A small core plus loadable kernel modules added at runtime. The mainstream compromise — flexible like microkernels, fast like monolithic. Linux, macOS.
Hybrid
Mixes the above. A small-core structure but most services run in kernel space for speed. Windows and macOS are commonly called hybrid.
Fig 1 — Monolithic packs everything into the kernel; microkernel pushes most services to user-space servers that communicate by messages.
07 Booting
On power-on, firmware (BIOS/UEFI) runs a bootstrap program from ROM. It finds the kernel on disk, loads it into memory, and jumps to it. The kernel initializes hardware, mounts the root file system, starts core services, and launches the first user process (init/systemd on Linux), which starts everything else. A multi-stage boot loader (like GRUB) usually sits in between, letting you pick which kernel to boot.
common catches & gotchas
- API ≠ system call — You almost never call system calls directly; you call library functions that wrap them. Confusing the two is a classic mistake.
- System calls are expensive — Each crossing into the kernel costs hundreds of cycles (mode switch, validation). That's why high-performance code batches I/O instead of making millions of tiny calls.
- The shell isn't the kernel — It's an ordinary user-mode program. Killing your shell doesn't touch the OS.
- "Layered" sounds ideal but isn't used pure — Strict layering is slow and hard to partition cleanly, so real systems blur the layers. It's a teaching model more than a shipping design.
- Microkernel robustness has a price — Moving drivers to user space means more message passing; the cost is why mainstream kernels are modular, not pure microkernels.
08 Questions students actually ask
Why not let programs skip system calls for speed?
Because any bug or attack would then control the whole machine, and every program would need to know every device's details. The system-call wall makes the system safe and portable; the overhead is the price.
What's the difference between an API and a system call?
An API (like printf) is what your code calls — convenient and portable. Underneath it may issue one or more system calls (write) to do the privileged work.
Is the shell part of the kernel?
No. It's a system program running in user mode, like any app. It reads your commands and asks the kernel (via system calls) to run them.
Why do modular kernels dominate today?
They combine a fast in-kernel core with the ability to load/unload drivers and file systems at runtime — flexible like a microkernel, fast like a monolith — without rebuilding the kernel.
What actually happens during a system call?
The program sets a call number and arguments, executes a trap instruction that switches to kernel mode, the kernel validates and runs the service via the system-call table, returns the result, and switches back to user mode.
09 Key takeaways
- The OS offers services to users and a system-call interface to programs.
- A system call traps into kernel mode, runs vetted code via the system-call table, and returns.
- Calls group into six families: process, file, device, information, communication, protection.
- System programs (shells, editors, utilities) wrap the kernel and are what users touch.
- Kernel designs — monolithic, layered, microkernel, modular, hybrid — trade speed, simplicity, robustness.
- Modern systems are modular/hybrid: a fast core plus loadable modules.
- Booting goes firmware → boot loader → kernel → first user process.
10 Wrapping up
This is the "how do I reach the OS, and how is it built" chapter. The system-call interface is the contract every program depends on; the kernel structure is an engineering choice with real trade-offs. Next up: Processes.