How read() Really Works: From Syscall to Disk and Back

Every time your program calls read(), a remarkable journey begins. What looks like a simple function call triggers a cascade of operations spanning user space, the Linux kernel, the VFS layer, filesystem drivers, and finally the hardware itself.

The Journey Begins in User Space

When you call read(fd, buf, count)in C, you're actually calling a wrapper function in glibc. This wrapper sets up the necessary registers and executes the syscall instruction (or int 0x80 on older systems), transferring control to the kernel.

// What glibc does internally
// On x86_64:
mov rax, 0        // syscall number for read
mov rdi, fd       // file descriptor
mov rsi, buf      // buffer address
mov rdx, count    // byte count
syscall           // trap to kernel

Kernel Entry

The kernel receives the syscall, validates the arguments, and dispatches to the sys_read()function. Before any I/O happens, the kernel checks permissions and verifies the file descriptor is valid.

The VFS Layer

Linux's Virtual File System (VFS) provides a unified interface for all filesystem types. Whether you're reading from ext4, tmpfs, or a network filesystem, the kernel calls the same VFS operations, which then delegate to the specific filesystem implementation.