The case
Three programs, one processor. Who decides who runs?
Isaac keeps the stock spreadsheet, the video call with the supplier and the order system open at the same time, on a single computer. None of the three brings down the others, and none can read its neighbor's memory.
Someone has to decide who uses the processor right now, how much memory each one gets and who can open each file.
The kernel is a program: the central software of the operating system. What sets it apart from other programs is not what it is, but the power it has over the hardware.
The problem
Programs can't talk straight to the hardware
A computer has one processor, one memory and one disk, and dozens of programs that want to use them. If each one talked straight to the hardware:
- Collisions: two programs would write to the same place in memory, and one would overwrite the other.
- Insecurity: a malicious program would read another one's passwords.
- Repetition: every program would need to know how to operate every model of disk, network card and keyboard.
- Chain failures: a bug in one program would freeze the whole machine.
The solution
The kernel
The kernel (the core) is that program: the part of the operating system that runs with full privileges over the hardware. It is the first thing loaded when the computer turns on, and it stays in memory the whole time. Ordinary programs ask it for what they need, and it decides whether to grant it.
Think of the counter at Isaac's café. The customer doesn't walk into the kitchen: they place an order at the counter. The attendant checks that the order is allowed, takes it to the kitchen, comes back with the result and manages the queue when a crowd shows up. The customers are the programs, the order is the system call, the kitchen is the hardware and the attendant is the kernel.
The kernel has four main jobs:
Processes and processor (process management)
Decides which program uses the processor and for how long, and switches between them so fast that they seem to run together. The part that does this is the scheduler.
On Isaac's computer: the video call and the spreadsheet take turns on the processor.
Memory (memory management)
Gives each program its own view of memory, the virtual memory, and stops one from touching another's.
On Isaac's computer: the order system can't see the spreadsheet's memory.
Files (file systems)
Organizes the disk into folders and files, and controls who can read and write each one.
On Isaac's computer: only the right user opens the customers folder.
Devices (device drivers)
Talks to the hardware through drivers, and hides the differences between one model and another.
On Isaac's computer: the same program prints on any printer.
The network also goes through the kernel: it builds and delivers the packets of data that a program wants to send.
The boundary
User space and kernel space
The processor has two operating modes. In privileged mode, the kernel runs, and it can do anything. In restricted mode, ordinary programs run, and they can't touch the hardware or other programs' memory directly. That is why we talk about two areas:
- User space: where applications run.
- Kernel space: where the kernel runs.
To do something only the kernel can do, like opening a file or sending data over the network, a program makes a system call (or syscall). It is a formal request: the processor switches to privileged mode, the kernel checks that the request is allowed, carries it out and returns the result.
Some Linux system calls: open (open a file), read and write (read and write), fork (create a process) and mmap (map memory).
Don't mix them up
Kernel × operating system
The two names are used as if they were the same. They aren't.
Kernel
“Who controls the hardware and divides resources among the programs?”
- Example
- Linux, the core used by Ubuntu, Debian and Android.
- Focus
- The core: processes, memory, files, devices and network.
Operating system
“What does the user get, ready to use the computer?”
- Example
- Ubuntu: the Linux kernel, plus the terminal (shell), the libraries, the utilities and the interface.
- Focus
- The kernel plus everything that comes around it.
Inside
Kernel types
There are different ways to organize a kernel:
| Type | What it is like | Example |
|---|---|---|
| Monolithic | Almost everything (processes, memory, files, drivers) runs inside the kernel. It is fast, but a bug in a driver can bring the system down | Linux |
| Microkernel | The kernel is minimal, and the other services run as separate programs. There is more isolation, and more requests between the parts | Minix, QNX |
| Hybrid | Mixes the two ideas | Windows (NT), macOS (XNU) |
Linux is monolithic, but modular: it accepts kernel modules, pieces of code such as drivers that are loaded and unloaded while the system is running, without a reboot.
In practice
Why this matters if you build software
The kernel shows up in the daily work of anyone who develops or operates systems:
A crashed program (process isolation)
When a program fails, the kernel ends only that process. The rest of the system keeps going.
On Isaac's computer: the video call freezes, and the spreadsheet stays open.
Running out of memory (out of memory)
If memory runs out, the Linux kernel may kill a process to save the system. It is the OOM killer.
On a server: the database vanishes, and the kernel log says why.
Watching system calls (strace)
On Linux, the strace tool shows the system calls a program makes.
Servers, VMs and containers
All of this runs on top of a kernel: each virtual machine has its own, and containers share the server's.
strace -c lsThe command counts the system calls made by a plain ls, from openat to write.
Key terms
Six terms to remember
Tap a card to see the definition.
Quick test
Three questions, exam style
01
A program needs to read a file from disk. How does it do that?
02
Strictly speaking, what is Linux?
03
An ordinary program tries to read another program's memory. What happens?
The kernel is the referee between programs and hardware: it divides the processor, memory, files and devices, and only serves what is allowed, through system calls. Understanding that boundary explains why a bug in an ordinary program doesn't bring the whole machine down, and why almost every tool, from a text editor to a database, depends on the kernel. The next step is to understand what runs on top of it: Processes and Threads.