The Kernel: the Operating System's Core That Governs Everything
Last lesson we said a program asks at the official counter (a system call), and the instant it crosses, it briefly flips to kernel mode. But behind that counter, who is it that actually does the work with such powerful privilege? And why was that mode called kernel mode in the first place? Today we meet, face to face, the deepest center of the operating system, the core that always keeps its post.
Who Is Behind the Counter
Think back to last lesson. A program is penned inside a fence, cannot touch hardware directly, and when it needs work done, it asks at the official counter called a system call. And the instant it crosses, the CPU briefly flips to kernel mode, does the work, and comes back. Back then we deliberately did not look at one thing: the being that, behind the counter, actually does the work with that powerful privilege. The counter is only the entrance that receives requests; inside it there is a separate worker who truly reads the disk and puts dots on the screen. The name of that worker is the kernel.
Tap the counter to look behind it. The core that was hidden behind the system-call counter, the kernel, is revealed. The one that actually handled the request was this kernel all along.
The kernel is revealed. Now even the name powerful kernel mode makes sense. That strong privilege is exactly the power this kernel uses when it works, so the name was given for it. But does this kernel only appear for a moment when a request comes in, then vanish? No. Next we look at from when and until when the kernel stays at its post.
The Kernel Is Always Awake
The programs we use turn on and off. We open a music app and close it, launch a browser and shut it. An app loads into memory when needed, and when closed it leaves memory. But the kernel is different. The instant the computer turns on, it is the very first to take its place in memory, and until the power goes off it never once leaves that place. No matter how many apps come and go, the kernel is always awake beneath them. When you think about it, that is only natural. Loading apps into memory and removing them, deciding who gets the CPU, all of that is done by the kernel. If the kernel fell asleep, there would be no one left to do that work.
Tap the apps to switch them on and off. The app slots turn on and off, but the kernel slot at the bottom stays on the whole time. The kernel lives in memory from boot to shutdown.
The apps flickered, but the kernel slot stayed steadily on. The kernel is like the person backstage who raises and lowers the curtain. The actors come and go, but that person keeps their post the whole show. So what exactly does the kernel do from that ever-present post? In fact, almost everything we learned in this area was turning in the kernel's hands all along. Next, let us gather it all in one place.
The Control Tower of Every Resource
Coming through this area, we learned many things. The scheduling that decides who gets the CPU first, the virtual memory that pretends to be bigger than real memory, the drivers that recognize a new device, the system that organizes files, and the permission check that sees who can do what. Back then we learned them separately, but in fact the hand that actually carries out all of this is one. It is the kernel. The kernel is like an airport's control tower. Just as the tower decides in one place when each plane takes off and lands and which runway it uses, the kernel governs from one hand how much of each resource, the CPU, memory, devices, and files, goes to whom.
Tap each resource one by one. Whichever you tap, CPU scheduling, memory, drivers, files, or permissions, the kernel in the center is highlighted as the one that governs it. Every resource turns in the kernel's single hand.
Whichever resource you tapped, the path gathered to the kernel. The tasks that seemed scattered were in fact turning around one center. But if the kernel does all this powerful work, is that not dangerous? It would be a disaster if just any program could use this power. So the computer divides the world of power into two. Next, let us look at that boundary.
The Boundary Between Two Modes
Let us recall the two modes we glimpsed last lesson. One is user mode, the power-limited world where our apps live. The other is kernel mode, the strong world where the kernel works and can touch hardware and anything else directly. Between the two there is a clear boundary. An app in user mode cannot reach straight for hardware. Only the kernel, in kernel mode, can touch hardware directly. So if an app tries to do something itself, it is blocked, and the work only happens when it asks the kernel and goes through kernel mode. Thanks to this boundary, the strong power is gathered in just one trustworthy place, the kernel.
Tap to switch the mode. In user mode, reaching straight for hardware is blocked (red). Only in kernel mode is hardware access allowed (green). The strong power lives only inside kernel mode.
In user mode it was blocked, and only in kernel mode did it go through. Having the strong power gathered in one place, the kernel, is reassuring. Since dangerous actions pass through only one place, you only need to guard that one place well. But at the same time, a slightly dizzying thought arises. If everything hangs on the kernel alone, what happens if a problem arises in that kernel itself? In the final stage, let us wrap up today's lesson with that question.
When the Kernel Stops
Let us gather today's lesson on one line. The kernel is the core program that does the actual work behind the system-call counter; it stays resident in memory from boot to shutdown; and it governs every resource, the CPU, memory, devices, files, and permissions, from one hand. The strong kernel mode is the power the kernel uses when it works. So this is what happens. Even if one app goes wrong and freezes or dies, the kernel above it is alive, so it just clears away that one app and the rest keeps running fine. That is why we can force-close one stuck app and keep using the computer. But if the kernel itself stops, the story is entirely different. The one hand that would clear away apps, hand out resources, and handle requests is gone, so every app above it and the whole system stop all at once. That rare moment when the computer suddenly turns blue or goes dead and has to be restarted is exactly when the kernel could hold on no longer.
Tap one app to make it stop. The kernel is alive, so just that app is cleared and the rest is fine. Finally tap the kernel to stop it, and everything above it halts all at once (red). Everything hangs on the one kernel.
Now the very center of the operating system comes into clear view. The scheduling, memory, drivers, files, permissions, and system calls we learned separately were all turning in this one kernel's hand. But when resources are handed out from one hand, a new headache appears. If two programs each hold onto what they have and only wait for the other's, both can stop forever. In the next lesson we meet the deadlock that happens when neither will give way.