System Calls Explained

Every time your program reads a file, sends a network packet, or even asks what time it is, it can't do that work itself. It has to ask the kernel — the core of the operating system — to do it instead, through a very specific, tightly controlled doorway called a system call. That doorway exists for a reason, costs something every time you walk through it, and understanding both facts explains a surprising number of real performance decisions you'll run into as a developer.

This guide covers why that doorway exists, what actually happens when you walk through it, and why the cost of doing so shapes how fast code is written in practice.

How to read this

Read it in order. Phase 1 explains why programs can't touch hardware directly — the wall between user mode and kernel mode, and the protection reason it exists. Phase 2 walks through the actual mechanics of a syscall: the trap, the mode switch, the syscall number and arguments, the return. Phase 3 is where it gets practical — why the cost of a mode switch is real, why buffering exists, and how tools like strace let you watch syscalls happen live. The mechanism is the same shape on Linux, macOS, and Windows, even though the exact instructions and tool names differ.

The phases

1. Why programs can't touch hardware directly — the wall between user mode and kernel mode, and why it exists.
2. What actually happens during a syscall — the trap, the mode switch, the syscall number and arguments, the return.
3. Why syscalls matter for real performance — the cost of a mode switch, why you buffer, and watching syscalls with strace.

Phase 1: Why programs can't touch hardware directly →