System Calls

In user mode the CPU refuses privileged instructions and the page tables hide every device and every kernel structure (see User Mode vs Kernel Mode). So the only way for a program to make anything happen outside its own memory is to ask the kernel. A system call is that request: a well-defined operation with a number and arguments, performed by the kernel on the caller’s behalf, with the caller’s identity and permissions checked at every step.

Everything your program does that is not pure computation on its own memory is a syscall underneath. Reading a config file: openat, read, close. Printing to the terminal: write on descriptor 1. Connecting to a database: socket, connect, then sendto/recvfrom or write/read. Waiting for a lock: futex. Allocating a large buffer: mmap. Starting a subprocess: clone (or fork) then execve. Waiting for 10,000 sockets: epoll_wait. The kernel is not a library you link; it is a service you call through a trap.

On x86-64 Linux the convention is: syscall number in rax, up to six arguments in rdi, rsi, rdx, r10, r8, r9, then the syscall instruction. The CPU saves the user instruction pointer and flags, switches to ring 0 and the task’s kernel stack, and jumps to the entry point the kernel registered at boot. The kernel indexes its syscall table by rax, calls the handler, puts the result in rax (a small negative number is -errno) and executes sysret. write is number 1, read is 0, openat is 257, mmap is 9, clone is 56, futex is 202, epoll_wait is 232. ARM64 Linux uses x8 for the number, x0–x5 for arguments and the svc #0 instruction; the numbers differ.

The libc wrapper is what makes this look like a function. write() in glibc is a few instructions: move arguments into place, syscall, and if rax is in the range −4095…−1 negate it into the thread-local errno and return −1. This is why errno exists — the raw kernel interface returns a negative error inline, and the C convention wanted −1 plus an out-of-band code. It is also why errno is per-thread: two threads making syscalls concurrently must not overwrite each other’s error.

Some "syscalls" never enter the kernel. clock_gettime, gettimeofday and getcpu are served from the vDSO, a page of kernel-provided code mapped into every process, reading a shared memory page the kernel updates; a timestamp costs ~20 ns instead of a trap. Runtimes that need timestamps on every event (Node’s event loop, Go’s scheduler, Python’s time.perf_counter) rely on this.

A few dozen syscalls cover almost everything a server does; they group naturally by what they touch. Learning them is learning the vocabulary of strace output, of kernel profiles, and of the documentation for every I/O library you will ever use. The names below are the Linux/POSIX ones; Windows has equivalents behind a different API (NtCreateFile, NtReadFile, NtCreateUserProcess…) reached through ntdll.dll rather than libc.

The kernel’s syscall interface is a binary ABI — numbers and registers — and almost nothing calls it directly. The C library (glibc or musl on Linux, libSystem on macOS, the CRT plus ntdll on Windows) wraps every syscall in a C function, and every language runtime calls those. Node.js reaches the kernel through libuv, which calls read/write/epoll_wait from libc. CPython’s os.read is a thin wrapper around libc read. A C++ std::ifstream ends in read through the standard library’s filebuf. The JVM’s NIO calls epoll_wait through JNI into libc.

Two notable exceptions prove the rule. Go on Linux issues syscalls itself, without libc, because its runtime needed control over which OS thread blocks; on macOS and Windows it goes through the system library because those platforms do not promise a stable raw-syscall ABI. Which is the second point: Linux guarantees the syscall numbers and semantics forever (Linus’s "we do not break user space"), while macOS and Windows guarantee only the library layer and reserve the right to renumber underneath. Statically linked Linux binaries run on any kernel; the same trick on macOS is unsupported.

This layering is why strace (Linux), dtruss (macOS) and Process Monitor (Windows) are so revealing: they sit at the syscall boundary and show exactly what a program asked the OS for, independent of the language it was written in. A Python script and a Rust binary opening the same file produce the same openat line.

The bare round trip — trap in, dispatch, trivial handler, return — costs on the order of 100–300 ns on a modern x86-64 core, and closer to 1 µs on kernels running with Spectre/Meltdown mitigations that flush predictors or switch page tables on entry. That is 100–1000× a function call. It is also a pipeline flush and a partial cache disturbance, so a syscall-heavy loop runs slower than the sum of its traps suggests.

The consequence is that the *number* of syscalls, not the bytes moved, often bounds I/O throughput. Writing a 1 GB file in 1-byte write calls is a billion traps; in 64 kB calls it is 16,000. Every I/O library buffers for this reason: stdio, BufferedWriter, Node streams and Python’s io all accumulate bytes in user space and issue one large write. Reading 10,000 sockets with one read each is 10,000 traps per pass; epoll_wait returns the ready ones in one call so you only trap for sockets that have data.

The kernel offers explicitly batched interfaces where the pattern is common: readv/writev move several buffers in one call; sendfile and splice move data between descriptors without a user-space copy (Zero-Copy: Serving a File Without Touching It); recvmmsg/sendmmsg handle many UDP datagrams per call; and io_uring (Linux 5.1+) goes furthest — the application writes requests into a ring buffer shared with the kernel and reads completions from another, and in polled mode does I/O with *no* syscalls at all. Every one of these exists because a trap costs more than the work it requests.