IN DEPTH Linux

As we delve into what makes Linux tick, your guide Matt Holder explains how abstraction keeps you safely away from hardware voltages.

I n this new series of articles, we are going to investigate some of the plumbing that is used to give us the incredible experience that we are used to with Linux distros. This ranges all the way from the kernel that performs interactions directly with the hardware to Wayland, the display server used to support our graphical user interfaces. Along the way, we will also meet PipeWire, which is used for audio and video routing around our systems. In some cases, we will also discuss the tools that these technologies are on the way to replacing, such as PulseAudio for audio playback and the venerable X in the case of Wayland.

Let’s begin at the beginning, introducing the Linux kernel, as this performs the direct interactions with your hardware and then provides methods for our software to interact with it.

In 1991, a Finnish student began work on a hobby project, which he called Linux. This was the humble beginnings of what we now use to interact with the hardware in our computers. Most people refer to Ubuntu or Fedora as a Linux distribution. Technically this is incorrect, as a lot of other tools are required to complete the operating system. One school of thought is that we should refer to these operating systems as GNU/Linux, which references the large number of GNU tools that are included.

CREDIT: Magictorch

Kernel architecture

Ubuntu uses the Linux kernel. By design this is a monolithic kernel, which means it carries out a lot of functions all running in kernel space (running with the same privileges). A monolithic kernel handles interprocess communication (IPC), filesystems, scheduling, virtual memory and device drivers, to name a few. In contrast, the footprint of a microkernel is as small as possible. In terms of functionality, a microkernel manages IPC, scheduling and virtual memory.

The GRUB menu can be used to set kernel options at boot time.

Everything else is managed in userspace by the kernel being able to communicate with corresponding services/daemons. For example, a device driver can communicate with the hardware by using a service that provides any data processing needed before the kernel then communicates this with the hardware.

Which kernel design has seized the day? Well, looking at examples of monolithic kernels – Linux, BSD, DOS, Unix – it seems that monolithic is the most popular. One school of thought is that having a kernel performing as few tasks as possible allows the code to be more rigorously tested and be more stable than a monolithic equivalent. Maybe a device driver crashes – using the microkernel example, the OS itself would not crash, but this hardware would be unavailable. A third kernel design exists, hybrid, which is a mixture of the two. The Windows NT kernel follows a hybrid model.