System calls — how programs politely ask the kernel for help

Ringing the doorbell instead of walking in

Imagine the teacher from Lesson 1 has an office with a locked door. Kids aren't allowed to walk in and grab supplies themselves — they have to ring a doorbell, ask for exactly what they need ("may I have a red crayon?"), and wait for the teacher to hand it through. This is precisely what a system call is: a strictly controlled doorbell that a program rings whenever it needs the kernel to do something it isn't allowed to do itself, like reading a file, sending network data, or creating a new program.

Ordinary programs run in user mode, where dangerous instructions (talking directly to disks, network cards, or other processes' memory) are physically disabled by the CPU. The only way to get those things done is to ask the one entity allowed to run in kernel mode: the OS kernel. A system call is that ask.

What actually happens when you call read()

1. The program places the system call number (an ID, like "this is call #3, read") and its arguments into agreed-upon CPU registers.
2. The program executes a special instruction (on x86, historically int 0x80, and on modern CPUs a dedicated instruction called syscall). This instruction is the "doorbell" — it's the only legal way to jump from user mode into kernel mode.
3. The CPU hardware itself switches to kernel mode and jumps to a fixed, trusted location in the kernel called the system call handler — the program cannot control where it jumps to, only that it rings the bell.
4. The kernel looks up the system call number in a table (the system call table), runs the real, privileged code to read the file from disk, and copies the result back into the program's memory.
5. The CPU switches back to user mode and returns control to the program, right after the point it called read().

The program feels like it just called an ordinary function, but underneath, control genuinely left the program, was handled entirely by trusted kernel code, and came back — with the hardware guaranteeing at every step that the program itself never got privileged access.

User program:  ... read(file, buf, 100) ...
                       │  triggers syscall instruction
                       ▼
CPU switches to kernel mode, jumps to fixed handler
                       │
Kernel:  looks up syscall #, checks permissions, does the real disk read
                       │
CPU switches back to user mode, returns result
                       ▼
User program:  ... continues with buf now filled ...

Why not just let programs call kernel functions directly?

Because that would defeat the entire point of user mode. If a program could jump to any address inside the kernel, it could skip all the permission checks and pretend to be a totally different, trusted piece of code. By forcing every single request through one fixed entry point, the kernel guarantees it always gets to check "is this program actually allowed to do this?" before doing anything privileged — reading someone else's file, for instance, or accessing memory it doesn't own.

System calls versus library functions — a common confusion

The math of why system calls aren't free

Switching between user mode and kernel mode isn't instantaneous — it involves saving the program's state, jumping to the kernel, and jumping back, which takes real CPU cycles even before the kernel does any actual work. Suppose one mode switch costs about $2{,}000$ CPU cycles on a given machine, and a program makes $50{,}000$ system calls per second (common for something I/O-heavy, like a busy web server):

$\text{cycles spent just switching modes per second} = 50{,}000 \times 2{,}000 = 100{,}000{,}000 \text{ cycles}$

On a 2 GHz CPU (2,000,000,000 cycles per second), that's:

$\frac{100{,}000{,}000}{2{,}000{,}000{,}000} = 0.05 = 5\%$

Common mistakes

1. Thinking every function you call is a system call. Only calls that need privileged kernel work are; most "OS-looking" functions are user-mode library wrappers around a much smaller set of real system calls.
2. Assuming a system call is as cheap as a normal function call. It isn't — it forces a hardware-enforced privilege switch, which has a real, measurable cost even before any actual work is done.
3. Believing user programs can call kernel code at any address. They can only enter through the single fixed handler; this is precisely what stops user programs from bypassing security checks.

A few more concepts worth knowing

• System call numbers: each system call is identified by a small integer (e.g. on Linux x86-64, read is number 0, write is 1); the kernel's syscall table is just an array indexed by this number.
• Blocking vs non-blocking calls: a blocking system call (like a plain read()) parks the process in the waiting state until data arrives; a non-blocking version returns immediately with "nothing available yet," letting the caller decide how to wait.
• The vDSO: modern Linux maps a small, read-only page called the vDSO into every process, letting a handful of very frequent calls (like getting the current time) run entirely in user mode with zero kernel crossing at all.
• POSIX: the standard that specifies most of these system calls' exact names and behavior, which is why the same open()/read()/write() pattern works almost identically on Linux and macOS.

Summary

A system call is the one legal doorway from user mode into the kernel's privileged territory, triggered by a special CPU instruction that hands control to a fixed, trusted entry point rather than letting a program jump anywhere it likes. Every privileged action — reading a file, sending a network packet, creating a process — ultimately goes through this doorway, and because the switch itself costs real CPU cycles, efficient programs try to make fewer, larger calls instead of many tiny ones.