the system-call table

Once the syscall instruction has carried a program into the kernel, the kernel still has to figure out which of its hundreds of services was actually requested - was this a read, a write, an open, a fork? The system-call table is how it decides: a simple array of function pointers, one slot per system call, indexed by the system-call number the program passed in. It is the kernel's switchboard, turning a number into the right handler.

Mechanically it is a plain lookup. Every system call has a stable number defined by the kernel's ABI - on Linux x86-64, read is 0, write is 1, open is 2, and so on - and these numbers essentially never change, because old binaries hard-code them. The program loads its chosen number into a register (rax on x86-64) before executing syscall; the kernel's entry code takes that number, checks it is in range, uses it as an index into the table, and calls the function pointer stored there. So requesting 'write' is really 'call the function at slot 1 of the table.' The numbers must be checked against the table size first, because a number out of range would otherwise index past the array - a memory-safety hole.

Why understanding the table is clarifying: it makes concrete that the kernel/user interface is a fixed, numbered contract, not a flexible API you negotiate at runtime. Adding a new system call means giving it the next free number and adding a table entry, and that number is then frozen forever for compatibility. A historical note worth flagging: the table was once a favorite target for rootkits, which would overwrite a table entry to redirect a system call to malicious code - which is why modern kernels make the system-call table read-only after boot, so it cannot be quietly hijacked.