What is a kernel

Who Is Behind the Counter?

Think back to the last lesson. A program sits inside a fence and cannot touch the hardware, so when it needs something done it asks at the official counter called a system call. The moment the request crosses, the CPU switches briefly into kernel mode, gets the job done, and comes back.
There was one thing we deliberately did not look at: whoever, behind the counter, actually does the work with that strong privilege.
The counter is just the entrance where requests are taken. Further inside is a separate worker that really reads the disk and puts dots on the screen. That worker is called the kernel.

Press the button and the hidden box behind the system-call counter opens to reveal the kernel. The one that actually handled the program's request was the kernel all along.

Now the name kernel mode makes sense. That strong privilege is the power the kernel uses while it works, which is why the mode is named after it.
Does the kernel, then, appear only for a moment when a request arrives and vanish again? Not at all.
When people use the term operating system in its narrowest sense, this kernel is what they mean.
When the kernel arrives and how long it stays is the next part of the story.

The Kernel Is Always Awake

The apps we use come and go. We open a music app and close it, start a browser and quit it. An app is loaded into memory when it is needed and removed when it is closed.
The kernel is different. It is loaded into memory while the computer boots, settles into its place, and does not leave that place once until the power goes off. However many apps come and go, the kernel stays awake underneath them.
On reflection that is only natural. Loading apps into memory and removing them, deciding who gets the CPU: all of that is the kernel's job. If the kernel fell asleep, nothing would be left to do it.

Each of the three app slots at the top switches on and off as you press it, but the kernel slot at the bottom stays lit the whole time. The kernel stays in memory from boot to shutdown.

The app slots flickered, but the kernel slot stayed steadily on. The kernel is a bit like the stagehand who raises and lowers the curtain. The actors come and go, but the stagehand is there for the whole show.
So what exactly does the kernel do from that post? In fact, almost everything in this area has been running in the kernel's hands.

The Control Tower for Every Resource

On the way through this area we learned a lot: scheduling, which decides who gets the CPU next; virtual memory, which makes memory look bigger than it is; drivers, which let the system talk to a new device; the file system, which keeps files in order; and permission checks, which decide who may do what.
We met them one at a time, but a single hand does all of this work: the kernel.
The kernel resembles an airport control tower. Just as a tower decides from one place when each plane takes off and lands and which runway it uses, the kernel decides from one place how much of each resource, the CPU, memory, devices, and files, goes to whom.

Press any of the five resources and the kernel box in the middle lights up. Whether it is CPU scheduling, memory, drivers, files, or permissions, the one in charge is always the kernel.

Whichever resource you pressed, the path led back to the kernel. Jobs that looked scattered were turning around one center all along.
But if the kernel does all this powerful work, is that not dangerous? It would be a disaster if any program at all could wield this power.
So the computer splits the world of power in two.

The Boundary Between Two Modes

Recall the two modes from the last lesson. User mode is the limited world where our apps live. Kernel mode is the world where the kernel works and can touch the hardware and anything else directly.
There is a clear boundary between them. An app in user mode cannot reach for the hardware; only the kernel, working in kernel mode, touches it directly. So when an app tries to do something itself, it is stopped, and the job gets done only when the app asks the kernel and the work passes through kernel mode.
Thanks to this boundary, the strong power sits in one trustworthy place: the kernel.

Use the left button to switch the mode and the right button to reach for the hardware directly. In user mode the reach is blocked (red); only in kernel mode is it allowed (green). The strong power lives only inside kernel mode.

It was blocked in user mode and went through only in kernel mode. Having the strong power gathered in the kernel is reassuring: dangerous actions pass through one place, so only that place needs guarding.
It also raises an unsettling thought. If everything hangs on the kernel, what happens when the kernel itself runs into trouble?

When the Kernel Stops

Let us gather what we have seen. The kernel is the core program that does the real work behind the system-call counter; it stays in memory from boot to shutdown; and it manages every resource, the CPU, memory, devices, files, and permissions, from one hand. Strong kernel mode is the power it uses while working.
So when one app goes wrong and freezes or crashes, the kernel beneath it is still alive: that one app is cleaned up and the rest keep running. That is why we can force-quit one frozen app and carry on using the computer.
If the kernel itself stops, the story is completely different. The one hand that cleans up apps, hands out resources, and handles requests is gone, so every app above it and the whole system stop at once. Those rare moments when the screen suddenly turns blue or nothing responds and the machine has to be restarted are exactly the moments when the kernel could no longer hold on. The blue error screen on Windows and the kernel panic on Linux are cases of exactly this.

Press one of the three apps and only that app stops; the others are fine. Then press the stop-the-kernel button at the bottom, and everything above it halts at once (red).

The center of the operating system is now in clear view. The scheduling, memory, drivers, files, permissions, and system calls we studied one by one were all running in this one kernel's hand.
Handing out resources from one hand brings a new headache, though. If two programs each hold on to what they have and wait only for what the other holds, both can stop forever.
The next lesson is about this deadlock, which happens when neither side will give way.