System Calls and Files

Two modes

Programs run directly on the CPU, at full speed; the kernel doesn’t interpret them instruction by instruction. So what stops a program from reading the whole disk, ignoring file permissions, or never giving up the CPU? The hardware does. The CPU has two modes ¹:

• User mode, where ordinary programs run. Privileged instructions, such as talking to a disk or a network card, are refused: trying one raises an exception, and the kernel will likely end the program.
• Kernel mode, where the kernel runs, with full access to the machine.

The machine starts up in kernel mode, so the kernel can set everything up before it starts any program in user mode ¹.

System calls

So a program does nothing outside its own memory by itself. To open a file, start a process, send data over the network, or even ask the time of day, it makes a system call, a request to the kernel ^{1 2}. Linux has a few hundred; early Unix had about twenty ¹.

A system call works through a special trap instruction ¹:

1. The program puts the call’s number and its arguments in agreed places, such as particular registers, and runs the trap.
2. The trap switches the CPU to kernel mode and jumps into the kernel, saving the program’s registers so it can resume later.
3. The kernel looks up the call’s number in a trap table that it set up at boot. A program can’t jump to an address of its choosing inside the kernel; it only gets the handlers the kernel chose.
4. The kernel checks the request, for example the file’s permissions, and does the work.
5. A return-from-trap instruction switches back to user mode and resumes the program, with the result.

You never write the trap yourself. In C, open() looks like an ordinary function, and it is: a function in the C library containing the few instructions that set up and make the trap ¹. Python’s os.open, os.read, and os.write are thin wrappers around the same calls ³, and everything else, Python’s open() and print() included, ends up making them.

The kernel also gets control a second way: interrupts from hardware. The timer from lesson 1 is one, and a disk raises another when a read it was given has finished, so the kernel can move the waiting process from Blocked to Ready ¹.

Bash’s time (lesson 1) separates the two worlds: user is CPU time in the program’s own code, and sys is CPU time spent in the kernel working for it, mostly inside its system calls ⁴.

File descriptors

open() returns a file descriptor: a small, non-negative integer that refers to an entry in the process’s own table of open files. Later calls, read, write, close, take that number rather than the file’s name. A new descriptor is always the lowest number not already in use ⁵.

Every process starts with three already open ¹:

So the first file a program opens gets descriptor 3. For each open file the kernel also tracks an offset, where the next read or write will happen; each read or write moves it forward ¹.

This program uses the low-level calls directly. Save it as fds.py:

# fds.py: read and write through file descriptors, as the kernel sees files.
import os

with open("foo", "w") as f:
    f.write("hello\n")

fd = os.open("foo", os.O_RDONLY)
print("open returned", fd, flush=True)
print("read:", os.read(fd, 4096), flush=True)
print("read again:", os.read(fd, 4096), flush=True)
os.close(fd)

os.write(1, b"written to fd 1, standard output\n")
os.write(2, b"written to fd 2, standard error\n")

me@linuxbox:~$ python3 fds.py
open returned 3
read: b'hello\n'
read again: b''
written to fd 1, standard output
written to fd 2, standard error
me@linuxbox:~$ python3 fds.py 2> errors.txt
open returned 3
read: b'hello\n'
read again: b''
written to fd 1, standard output
me@linuxbox:~$ cat errors.txt
written to fd 2, standard error

open returned 3, as promised. The first read asked for up to 4,096 bytes and got the 6 in the file; the offset then sat at the end, so the second returned nothing, b'', which is how a program learns it has reached the end of a file ¹. Writing to descriptor 1 or 2 needs no open at all. (flush=True makes print hand its text to the kernel immediately, so the lines appear in the order written.)

Watching with strace

strace runs a program and prints every system call it makes, with the arguments and the return value ⁴. (If it’s missing, sudo apt install strace.) Here is the trace of cat foo from the OSTEP textbook, with many calls removed for readability ¹:

prompt> strace cat foo
...
open("foo", O_RDONLY|O_LARGEFILE) = 3
read(3, "hello\n", 4096) = 6
write(1, "hello\n", 6) = 6
hello
read(3, "", 4096) = 0
close(3) = 0
...

The whole of cat: open the file (descriptor 3), read up to 4 KB (6 bytes), write them to descriptor 1, read again (0 bytes, the end), close. The hello in the middle is cat’s actual output, mixed in with strace’s own, which goes to standard error ⁴.

On a current system you’ll see openat instead of open; since glibc 2.26, the C library’s open() uses the openat system call ⁵. A failed call returns -1 with the error’s name and message ⁴:

open("/foo/bar", O_RDONLY) = -1 ENOENT (No such file or directory)

Some useful options ⁴:

• -e trace=openat shows only those calls. strace -e trace=openat some-program answers “which config files is it reading?” faster than any documentation.
• -f follows child processes too. Trace a shell running a command and you’ll see lesson 1’s calls: clone, which the C library’s fork() uses on Linux ⁶, then execve and wait4.
• -c counts the calls and prints a summary table at the end.

Redirection, explained

The shell course’s redirections are about these numbers: the 2 in 2> is descriptor 2. To run wc notes.txt > out.txt, the shell forks, and in the child, before the exec, closes descriptor 1 and opens out.txt. The lowest free number is now 1, so the file becomes standard output. Open descriptors survive exec, so wc writes to descriptor 1 as always, never knowing it’s a file ¹.

2>&1 makes descriptor 2 a copy of descriptor 1 ⁷. Redirections are carried out in order, left to right, which is why order matters ⁷:

me@linuxbox:~$ ls notes.txt nosuchfile > out.txt 2>&1
me@linuxbox:~$ cat out.txt
ls: cannot access 'nosuchfile': No such file or directory
notes.txt
me@linuxbox:~$ ls notes.txt nosuchfile 2>&1 > out.txt
ls: cannot access 'nosuchfile': No such file or directory
me@linuxbox:~$ cat out.txt
notes.txt

In the first, 1 goes to the file, then 2 copies 1: both in the file. In the second, 2 copies 1 while 1 is still the terminal, and only afterward does 1 move to the file.

A pipe works the same way. The pipe() system call creates a queue inside the kernel and returns two descriptors, one to read from and one to write into ^{1 3}; for ls | wc -l, the shell connects ls’s descriptor 1 to the writing end and wc’s descriptor 0 to the reading end, then execs both ¹.

What each call costs

Every system call is a round trip: trap, save registers, switch to kernel mode, check, work, switch back. That’s fast, but not free. This program writes a million bytes twice: once with a separate write() for each byte, once through Python’s normal file object. Save it as syscalls.py:

# syscalls.py: write a million bytes, one system call each, then buffered.
import os
import time

N = 1_000_000

start = time.perf_counter()
fd = os.open("test.bin", os.O_WRONLY | os.O_CREAT | os.O_TRUNC)
for _ in range(N):
    os.write(fd, b"x")                  # one write() system call per byte
os.close(fd)
print(f"os.write, 1 byte each:  {time.perf_counter() - start:.2f} s")

start = time.perf_counter()
with open("test.bin", "wb") as f:       # Python buffers, then writes big chunks
    for _ in range(N):
        f.write(b"x")
print(f"buffered file.write:    {time.perf_counter() - start:.2f} s")

os.remove("test.bin")

On a desktop PC:

me@linuxbox:~$ python3 syscalls.py
os.write, 1 byte each:  1.58 s
buffered file.write:    0.05 s

About thirty times slower, for the same million bytes in the same file. The file object from open() collects what you write in a buffer in your own memory and hands it to the kernel in large chunks ⁸, so a million f.write calls become a handful of system calls. That’s why the Python docs point ordinary programs at open() and keep os.write for low-level work ³; it’s also why print output sometimes shows up later than you expect, and why flush=True exists ⁸. Your numbers will differ, but the gap won’t close: crossing into the kernel costs far more than a function call.

Your turn

So

Programs run in user mode and can’t touch the hardware; for anything beyond their own memory they make system calls, trapping into kernel mode through a table the kernel controls, and returning with the result. Libraries, from C’s to Python’s, wrap those calls. Open files are file descriptors, small numbers indexing a per-process table: 0, 1, and 2 are standard input, output, and error, and the next open gets the lowest free number. strace shows every call a program makes. Redirection and pipes are the shell rearranging descriptors between fork and exec, in order, left to right. And each system call costs a trip into the kernel, which is why buffered I/O is so much faster.