a system call

An ordinary program cannot be trusted to touch the disk directly, send a network packet, or hand out memory, because it shares the machine with every other program and the hardware itself. Those powers are reserved for the operating system. A system call is the controlled gateway a program uses to ask the operating system to do one of these privileged things on its behalf. It is like a bank teller's window: you cannot walk into the vault yourself, but you can step up to the window and ask the teller, who is authorized, to fetch your money under the rules.

Mechanically, a system call is more than a normal function call because it crosses a protection boundary. The processor runs your code in a restricted user mode that forbids dangerous operations. To make a system call the program puts a number identifying the request (read, write, open, and so on) and its arguments in agreed registers, then executes a special instruction (ecall on RISC-V, syscall on x86) that traps into the kernel, switching the processor into privileged mode and jumping to a fixed operating-system entry point. The kernel checks the request, performs it if allowed, places a result in a register, and returns control to your program back in user mode. The cost of that switch is real, which is why system calls are noticeably more expensive than ordinary calls.

System calls matter because they are the seam where software stops being able to do whatever it likes and must ask permission. Everything a program does with the outside world (files, network, time, new processes, more memory) ultimately goes through them. They are also a security cornerstone: the user/kernel boundary is what stops a buggy or malicious program from trampling the rest of the system, which is why the only door through it is this narrow, guarded one. Most programmers never write the raw instruction; they call library functions that perform the system call underneath.