Linux is just a kernel, but as Jonni Bidwell discovers there’s an awful lot going on in there…

E xplaining what Linux is to senior management types can sometimes be tricky. An operating system, a monolithic kernel written in C, or a way of life are all valid answers. But so too is, to paraphrase Morpheus from The Matrix, “no one can tell you what Linux is, you have to experience it for yourself”. Fortunately, the fact you’re reading this magazine suggests you have some interest in Linux, maybe even some experience, and so we’ll treat you to a kernel deep-dive the likes of which would have management quaking in their boots.

The Linux Kernel is at the heart of all your favourite distros. It’s the interface between hardware and software, so it contains all the device drivers, networking stacks and weird protocols required to get your system from the BIOS into a usable state (via the bootloader), and hopefully keep it that way. It has direct access to the CPU and memory, so when userspace programs want to access those, they do so via kernel calls. The kernel then dutifully allocates memory, gets the CPU to do the required sums, and gives back the requested result.

Windows and macOS have kernels, too – it’s just that those kernels are much more tightly coupled with their respective OSes. Android uses the Linux Kernel, but buried deep beneath layers of Java-flavoured abstractions that make it utterly unlike a conventional Linux distribution. But enough about lesser OSes. We’re here to find out what makes the Linux kernel tick, how it has developed and even how to make it tick faster. So without further ado, on with the show!

How does the kernel work?

While you’re reading this, your computer’s kernel is a hive of activity.

When you power on your Linux box the BIOS or UEFI jump into life and do all kinds of checks and initialisations to get it into a state capable of running an OS. Once that’s done it hands over to the bootloader (GRUB or systemdboot, say) whose job is to load the kernel into memory, start an initial RAM disk or filesystem (initrd or initramfs) and then hand over to the init process, known as PID1 since it’s the first process to start. And also the process that spawns all other processes.

It’s not always strictly necessary to use an initrd, but most distros do this because it simplifies the process of accessing the root filesystem, which might need certain drivers to be loaded before it can be accessed. This so-called early userspace contains everything required to detect hardware, load modules and mount the root filesystem. Oh, and if you’ve ever used the hibernate function, which dumps the current system state to disk, then it’s the initramfs that ensures that image can be read when you power the system back on.

We’ve already skipped way past the kernel by this point, but that doesn’t matter, because from the moment it’s loaded the kernel becomes the gatekeeper of system hardware. When your initrd goes looking for a filesystem with a particular UUID, it does so via the kernel. When it wants to query what kind of filesystem that is, it does so via the kernel. The filesystem (for example, ext4 or btrfs) and interface (SCSI or ATA, say) modules are packed into the initramfs so they can be loaded (again by the kernel) and before you know it

Systemd (or whatever is your PID1) has taken over your system. Except it hasn’t, because everything Systemd and everything that comes after does is done through the kernel. Kernel calls run in a privileged mode, which is even more privileged than the root account if you like, since all root does gets vetted by the kernel too.