What an operating system does
The operating system turns raw hardware into something programs can safely share. Follow a single read() call across the boundary between user mode and the kernel, and see the three illusions every OS provides.
In this lecture you will
- Describe the kernel’s job as resource manager and referee
- Explain user mode, kernel mode and why the boundary exists
- Trace a system call from a program down to a device and back
- Name the main abstractions an OS provides — processes, virtual memory and files
Your laptop is running hundreds of programs right now: a browser with dozens of tabs, a chat app, background updaters, the window system. They all share a handful of CPU cores, one pool of memory and one disk — and none of them can crash or spy on the others. Making that possible is the job of the operating system.
The kernel: manager and referee
The core of an operating system is the kernel: the program that starts first, stays resident and has complete control of the hardware. It plays two roles:
- Resource manager — deciding which program runs on which CPU core, who gets how much memory, and in what order disk and network requests are served.
- Referee — keeping programs isolated from each other and from the hardware, so a bug in one program can’t corrupt another or the system itself.
Linux, Windows and macOS all have kernels that do these jobs, with different designs underneath. Around the kernel sit system libraries, services and tools that together make up the full “operating system”.
Two modes: user and kernel
The key to isolation is in the CPU itself. Modern processors run in at least two privilege levels:
- User mode
- Where ordinary programs run. Instructions that touch devices, change memory mappings or disable interrupts are forbidden.
- Kernel mode
- Where the kernel runs, with full access to hardware and all memory.
- Trap
- A controlled jump into the kernel — caused by a system call, an error such as dividing by zero, or an interrupt from a device.
If a user program tries a privileged instruction, the CPU refuses and hands control to the kernel, which usually terminates the offender. That is why a bad pointer in one app gives you a crash report instead of a corrupted disk.
Try it. Each line below leaves user mode in a different way; watch what the kernel decides:
Each snippet was compiled and run as a normal user on Linux. System calls always return — possibly with an error code the program can handle. Faults the kernel can’t fix end the process with a signal, and the shell reports it.
System calls: asking the kernel for help
Since programs can’t touch hardware, they ask the kernel through system calls — a fixed set of requests such as open a file, read bytes, create a process, send on a socket. Scroll through what happens when a program reads from a file:
- 1The program calls read()
Your code asks for 4,096 bytes from an open file. It runs in user mode and cannot reach the SSD itself.
- 2The library makes the system call
The C library (or your language runtime) puts the system-call number and arguments in registers and executes the special syscall instruction.
- 3Trap into the kernel
The CPU switches to kernel mode and jumps to the kernel’s handler, which validates the request: is this a real open file? Is the buffer inside the program’s own memory?
- 4The file system looks for the data
The kernel checks its page cache first — recently used file data kept in RAM. On a miss, it works out which disk blocks hold the bytes.
- 5The driver talks to the device
The device driver queues a request to the SSD. Meanwhile the process is put to sleep and the scheduler runs something else; an interrupt signals when the data arrives.
- 6Copy the data and return
The kernel copies the bytes into the program’s buffer, switches back to user mode and returns the number of bytes read. To the program, it was just a function call.
On Linux you can watch this live: strace -c python3 script.py lists every system call a program makes and how long they took. It is an eye-opening tool the first time you use it.
Every system call has a fixed cost, so how many you make matters as much as how much data you move. Choose the buffer size a program passes to read():
Measured on a Linux laptop with a C program and the file already cached in memory: about 1.6 µs per read() call and 0.2 ms per megabyte copied. Buffered I/O — C’s stdio, Python’s open(), Java’s BufferedReader — reads several kilobytes at a time for you, which is why it is the default.
Three illusions
The best way to understand an operating system is through the illusions it creates. Each gets its own lecture in this module:
- Every program has its own CPU. In reality, the kernel switches between programs thousands of times a second. (Processes and scheduling — lectures 2 and 3.)
- Every program has its own private memory, starting at the same addresses and larger than the physical RAM. (Virtual memory — lecture 5.)
- Storage is a tidy tree of named files, not millions of numbered blocks on a device. (File systems — module 2.)
Next, we look at the first illusion: how a program on disk becomes a running process.
Key takeaways
- The kernel manages the CPU, memory, storage and devices so many programs can share them safely.
- Hardware enforces two privilege levels; ordinary programs run in user mode and cannot touch devices directly.
- Programs request kernel services through system calls, which switch the CPU into kernel mode and back.
- The OS provides three powerful illusions — each program has its own CPU, its own memory and a tidy file system.
Check your understanding
3 questions · answers explainedQ1Why can’t a normal program read a disk directly by talking to the hardware?
Q2What happens during a system call?
Q3A read() needs data from the SSD. What does the kernel typically do with the process while the device works?