The chicken-and-egg problem of starting up
Everything we have built up in this rung assumes the kernel is already running, already sitting in kernel mode, ready to answer a system call. But when you first press the power button, none of that exists yet. Memory holds garbage, the disk is just a slab of bits, and there is no program in charge. The very thing that loads programs is itself a program that must somehow be loaded. That is the chicken-and-egg riddle of starting a computer: who loads the loader?
The answer is a relay race. Each runner is tiny, just smart enough to find the next runner and hand off control. The race starts with a sliver of code burned into a chip on the motherboard, code that exists before any disk is read. That firmware finds a slightly bigger program, which finds a bigger one still, which finally finds and loads the kernel. The word boot is short for bootstrap, from the absurd image of pulling yourself up by your own bootstraps, which is exactly what the machine appears to do.
The boot relay, step by step
Let us trace the boot process on a typical modern PC. The torch passes from firmware to a small loader to the kernel, and each handoff narrows what runs and widens what it can do. On older machines the firmware was called the BIOS; today it is almost always UEFI, a richer firmware that understands modern disks and can verify signatures.
- Power-on. The CPU starts executing firmware code from a fixed address baked into the chip. The firmware runs a quick self-test, then probes for memory, disks, keyboard, and other hardware.
- Find the boot device. The firmware reads a tiny first chunk of the chosen disk, historically the boot block, and from it locates the bootloader, a small program whose only job is to load an operating system.
- Load the bootloader. The bootloader may show you a menu (pick Linux or Windows), then it reads the kernel image off the disk into memory. On Linux it often also loads a tiny temporary root file system called the initramfs so the kernel has the drivers it needs to reach the real disk.
- Hand control to the kernel. The bootloader jumps to the kernel's entry point. The kernel sets up memory management, switches the CPU firmly into kernel mode, starts its own drivers, mounts the real file system, and finally launches the very first user-space process.
- Start the first process. That first process (often called init or systemd) becomes the ancestor of every other program. From here on the system you know is alive: login prompts, services, your apps.
Notice the shape: a short, dumb, trusted program loads a longer, smarter, less-trusted one, over and over. By the time real applications run, the chain has handed off through three or four stages. Many firmwares add a security step here, secure boot, where each stage cryptographically checks the next one's signature before running it, so a tampered bootloader or kernel is refused.
What sits in memory once the dust settles
After boot, memory is divided in two. The kernel occupies its own protected region and runs in kernel mode with access to every privileged instruction; everything else, your shell, your browser, the login screen, runs in user mode in its own space. The CPU's mode bit remembers which side is in charge at any instant, and it flips to the kernel side only through a controlled door, the trap that a system call fires. This is the great divide you met earlier in the rung; booting is simply how that divide first gets drawn.
Booting is also where the ideas from the previous guide come true. The kernel immediately enables interrupts and a timer, so it can practise time-sharing: handing the CPU to one program, then snatching it back on the next tick to give another a turn. That rapid juggling is what lets multiprogramming keep many programs in memory at once. None of it happens until the kernel is up, which is the whole reason boot matters.
How the kernel itself is built: three blueprints
Now that the kernel is running, what is inside it? A kernel has to provide many services, process scheduling, memory management, file systems, network stacks, dozens of device drivers. The big design question, the heart of kernel structure, is which of these run inside the protected kernel and which run as ordinary user-mode programs. Where you draw that internal line gives three classic blueprints.
The first is the monolithic kernel. Everything, schedulers, drivers, file systems, networking, lives together in one big program running in kernel mode. It is like a hospital where every department shares one open floor: a doctor can hand a chart to a nurse by reaching across the room, so it is blazingly fast. The cost is fragility, a buggy driver shares the same address space as everything else, so it can corrupt the whole kernel and bring the machine down. The Linux kernel is the famous example, though it softens the rigidity with loadable kernel modules that can be plugged in and out at runtime.
The second is the microkernel. Here the kernel is kept tiny: it does almost nothing but the bare essentials, basic scheduling, basic memory protection, and message passing. The file system, the drivers, the network stack are pushed out into separate user-mode server processes, and they talk to each other and to clients through inter-process communication. Picture each hospital department behind its own locked door, passing notes through a slot. If one department burns down, the others keep running and you can restart it. The price is speed: every note through the slot is an IPC round trip, and what was a single function call in a monolith becomes several messages crossing the kernel boundary.
Hybrids, and what real systems actually do
In practice almost no major OS is a pure microkernel, because the IPC cost is too steep for the hottest paths. So most real kernels are hybrid: they keep the structure and many servers of a microkernel design but pull the performance-critical pieces (like the scheduler or the graphics path) back inside kernel mode for speed. A hybrid kernel is an honest engineering compromise, not a cop-out. The Windows NT architecture and Apple's XNU kernel are both described this way.
kernel mode | user mode monolithic: [ALL services]| apps microkernel: [tiny core] | fs, drivers, net (servers) + apps hybrid: [core + hot] | some servers + apps
There are even more radical blueprints worth knowing the names of. An exokernel strips the kernel down further still, exposing raw hardware to applications and letting them implement their own abstractions. A unikernel goes the other way and fuses a single application with just the OS pieces it needs into one bootable image, with no user/kernel split at all, handy for tightly scoped cloud workloads. These are not what runs on your laptop, but they show that the line between kernel and user is a design choice, not a law of nature.
Step back and the whole rung clicks together. An OS is a resource manager and an abstraction layer; the kernel is the privileged core that enforces the divide between itself and your programs; the system call is the doorway through it; multiprogramming and time-sharing are what it does with the CPU; booting is how it all gets switched on; and kernel structure is the floor plan of the manager's own office. You now have the full ground floor, and the rungs above will furnish each room.