Your program runs in user mode, a deliberately restricted setting where it *cannot* touch the disk, talk to a device, or start another process — those instructions are blocked by the CPU. So how does a program ever read a file? It asks the kernel. A system call is that request: the one controlled doorway from unprivileged user code into the privileged kernel mode where the OS core runs.
Crossing the boundary: the trap
1The program loads a system-call number (which service it wants) and the arguments into agreed-upon CPU registers.
2It executes a trap instruction — a special instruction whose *only* job is to switch the CPU into kernel mode and jump to one fixed, trusted entry point.
3The CPU flips to kernel mode and lands in the kernel's dispatcher, never at an address the program chose.
4The dispatcher uses the call number to index the system-call table and find the matching handler (for example, sys_read for read()).
5The handler does the privileged work — driving the disk, copying bytes — then returns a result and switches the CPU back to user mode, resuming the program right after the trap.
Why a trap and not a normal call
An ordinary function call would let user code jump *anywhere* in the kernel and run privileged instructions of its choosing. The trap is the whole protection story: it enters the kernel at one controlled door, so the OS — not the caller — decides what runs in privileged mode.
// In C you call read() like an ordinary function...
ssize_t n = read(fd, buf, count); // fd & buf passed via registers
// ...but inside, libc runs a trap instruction, crossing into the kernel.
if (n < 0) perror("read"); // a negative result means error
Notice you never write the trap yourself. The C library (libc) wraps each system call in a friendly function; underneath, that wrapper sets up the registers and fires the trap. That's why read() *looks* like a normal call even though it crosses into the kernel.
The families of services
1Process control — fork, exec, exit, wait: create, run, and end processes.
2File management — open, read, write, close: work with files and directories.
3Device management — request, release, and ioctl on devices.
4Information maintenance — getpid, time, and reading or setting system data.
5Communication & protection — pipes and sockets between processes, and permission checks like chmod.
System calls aren't free
Every call pays for a mode switch: saving registers, entering the kernel, and returning — often hundreds of nanoseconds, far more than a plain function call. That's why I/O is buffered: programs do one big read() of many bytes instead of one call per byte.
OperationTimeSpace
User function call · stays entirely in user mode~1 nsone stack frame
System call (trap) · mode switch + handler run~hundreds of nssaved register state
Check yourself
What is the essential role of the trap instruction in a system call?