a system call

A system call is the controlled doorway through which a user program asks the operating system to do something it is not allowed to do itself. Imagine a bank: you cannot walk into the vault and take cash, but you can step up to the teller window, fill out a slip, and request a withdrawal. The teller (the kernel), who is trusted and behind the counter, checks your request and does the privileged work for you. A system call is that teller window — the one official, guarded passage from user mode into the kernel.

Mechanically, here is what happens on a system call. The program puts the request number (which service it wants, e.g. read) and the arguments (which file, where to put the bytes, how many) into agreed-upon registers, then executes a special trap instruction. That instruction switches the CPU into kernel mode and jumps to a single fixed entry point in the kernel. The kernel looks up the request number in its system-call table, validates the arguments (is this a real file descriptor? is the buffer in the program's own memory?), performs the privileged work, places a return value, switches back to user mode, and resumes the program right after the trap. From the program's side it looks almost like an ordinary function call that happens to be unusually powerful.

System calls are the entire surface through which programs reach the operating system's services — opening files, creating processes, allocating memory, sending network data all happen through them. Two honest points matter. First, a system call is more expensive than a plain function call because of the mode switch and validation, so well-written programs avoid making millions of tiny ones (they batch, or buffer). Second, the kernel must never trust the arguments a system call hands it — a malicious program will pass bad pointers and out-of-range values on purpose, so careful checking at this boundary is a core part of OS security.