System calls

Why your app can't just read the disk itself

A system call is a program's request to the kernel (the OS core that owns the hardware) to do privileged work. Apps run in user mode, where the CPU blocks device instructions; only the kernel, in kernel mode, may run them.

Say a text editor saves your notes. It can't touch the disk, and kernel memory is marked supervisor-only in its page tables. So it puts a request number (write is 1 on x86-64 Linux) in a register and runs the `syscall` instruction.

That instruction enters kernel mode at one fixed entry point. The kernel looks up the number, checks the arguments and writes the file. Then `sysret` returns to user mode with the result: bytes written, or a negative error code.

System calls

Run strace and watch ls ask the kernel for every file

On Linux, the `strace` tool prints each system call a program makes. Running `strace ls` shows lines like `openat(...)` to open the folder, `getdents64(...)` to read its entries, and `write(1, ...)` to print the names to your terminal.

Even a tiny command makes dozens of these calls, since every file, screen output, memory request (`mmap`) and exit goes through the kernel. Python's `open` and C's `printf` are wrappers that end in these calls.

System calls

One guarded door into the kernel keeps every app honest

Apps can enter the kernel only at that one entry point, so they can't skip its checks. The kernel verifies each request, like whether a pointer lies in your memory, and returns an error such as EFAULT for a bad one.

So one buggy or hostile app can't crash the kernel or read another app's files.

The price is time: each crossing switches privilege mode and saves registers, costing roughly 0.1–1 µs, far more than a function call. So `printf` buffers text and calls write once per few kilobytes, not per character.