From lesson 1-3, guests in the hotel model never walk into the kitchen and cook. They order room service, and the OS equivalent is that programs make requests to the OS.
Programs never touch hardware directly, they ask. This unit gives that request its real name, the system call, and shows the wall that makes asking mandatory rather than merely polite.
Two privilege levels, enforced by the CPU
This boundary is where the OS's authority physically lives, and it shows up in daily engineering. Profilers report time spent in syscalls, container security is a policy about which syscalls a process may make, and "too many small writes" performance bugs are really "too many boundary crossings". Knowing the wall exists changes how all three read.
The separation between programs and the OS is not a polite convention, it is built into the CPU hardware, which runs in one of two modes.
| Mode | Who runs in it | Privileged instructions |
|---|---|---|
| user mode | your programs | physically disallowed |
| kernel mode | the kernel | all allowed |
In user mode, instructions that touch hardware, another process's memory, or privileged settings are physically refused, and attempting one triggers a trap that usually kills the process, which is the segfault from lesson 4-2. In kernel mode, everything is allowed.
The phrases user space and kernel space mean the code and memory living on each side of this wall.
A program reads a file or sends a packet by asking the kernel to do it, through a system call, often shortened to syscall. That is a special CPU instruction which safely switches into kernel mode at a fixed, kernel-controlled entry point, runs the kernel's code for the request, and then returns to user mode with the result.
The core syscall vocabulary
A handful of system calls underlie almost everything a program does. On Linux the big ones are:
| Syscall | What it does | You have been using it via |
|---|---|---|
open | get access to a file | open("notes.txt") in unit 7 |
read and write | move bytes in or out | f.read(), f.write(), print() |
fork plus exec | create a process, load a program | subprocess.run in lesson 3-3 |
exit | terminate, reporting an exit code | sys.exit(2) in lesson 3-3 |
The list is short on purpose. A modern kernel offers a few hundred syscalls, and ordinary programs spend nearly all their time in these five.
Each syscall is a mode switch into the kernel and back, which is why buffering exists as covered in lesson 7-2. Fewer syscalls means less boundary-crossing overhead, and that single trade explains most of the performance advice about I/O.
Why a program cannot move disk bytes itself
A Python program runs in user mode, where the CPU physically refuses privileged hardware instructions, so it cannot skip the kernel.
User mode is a hardware-enforced cage. Privileged operations trap instead of executing, and the trap hands control to the kernel rather than completing the instruction.
| Mechanism from earlier | Depends on user mode |
|---|---|
| process isolation, lesson 3-1 | yes |
| memory protection, lesson 4-2 | yes |
| multi-user security | yes |
That one mechanism is what makes all three possible at all. Without it, every rule the OS enforces would be a suggestion any program could ignore by writing to the hardware directly.
Naming the controlled request into the kernel
The controlled request a user-mode program makes to ask the kernel for privileged work is a system call, usually shortened to syscall.
It is the only doorway through the user and kernel wall: a special instruction that enters the kernel at a fixed entry point, runs the requested service, and returns to user mode with a result.
In the hotel model from lesson 1-3, it is the room service order. The guest never enters the kitchen, and the kitchen decides what it will and will not make.
Because the entry point is fixed and kernel-controlled, a program cannot jump into the middle of kernel code. It can only arrive at the door the kernel chose, which is what makes the boundary safe rather than merely conventional.