System Calls vs Library Functions

Library Functions: Ordinary Code, No Special Privilege

A library function - like a string-formatting or math function - runs entirely within a program's own regular memory space, using no special hardware privileges at all. It's just ordinary code, executed the same way any other part of the program runs.

System Calls: Requesting Something Only the Kernel Can Do

Application (user mode)
     |
     |  system call (e.g. "open this file")
     v
[ Kernel (kernel mode) ]  -- has the actual privilege to access the disk
     |
     v
Result returned back to the application

A system call is a formal request from an application, running in unprivileged user mode, asking the kernel (running in privileged kernel mode) to perform an operation the application itself isn't allowed to do directly - like reading a file, allocating memory, or creating a new process.

Why This Privilege Boundary Exists

If any application could directly manipulate hardware or access any file freely, one buggy or malicious program could corrupt the entire system or read another program's private data. Routing sensitive operations exclusively through system calls lets the kernel validate and control access before anything actually happens.

Why System Calls Have a Performance Cost Library Calls Don't

Making a system call requires a "mode switch" - transitioning from unprivileged user mode into privileged kernel mode and back again - which carries genuine overhead. A library function has no such cost, since it never leaves the user mode context the application is already running in.

Everyday Examples of Each

Why This Distinction Matters for Writing Efficient Code

Because system calls carry mode-switch overhead, code that makes an excessive number of small, unnecessary system calls (like reading a file one byte at a time) can run noticeably slower than code that batches the same work into fewer, larger system calls.