Linux concept: kernel

1. The Basics

The kernel is the central program of the operating system. It is the first real software the machine loads at boot, it stays in memory the entire time the computer is on, and it has complete control over the hardware. Everything else, from your shell to your web browser to a database server, is an ordinary program that runs on top of the kernel and asks the kernel whenever it needs to do anything real.

The reason for this design is protection. A modern CPU can run in two modes. In kernel mode a program may do anything: touch any memory, talk to any device, halt the processor. In user mode a program is fenced in: it can only use its own memory and must ask for everything else. The kernel runs in kernel mode. Every other program runs in user mode. This split is what stops one buggy application from crashing the whole machine or reading another program's private data.

So the kernel is best understood as a gatekeeper and a referee. When your program wants to read a file, it cannot open the disk itself; it asks the kernel, and the kernel checks your permissions, reads the right blocks, and hands back the data. When two programs both want the CPU, the kernel decides who runs and for how long. When a program asks for memory, the kernel finds it and keeps it separate from everyone else's.

The right mental model: the kernel is the one program that is allowed to talk to the hardware. Every other program on the system is a guest that must ask the kernel for anything real, and the kernel decides yes or no.

This article is about that core program: what it does, where the name comes from, how Linux came to be, how you inspect and tune your own kernel, and the surprising truth that almost everything your computer does is really a short request handed across the line into the kernel and back. The examples are verified against Linux kernel version 6.11.

1.1 Seeing Which Kernel You Run

You can ask your running kernel to identify itself with one command, uname (short for "unix name"). The most useful flag is -r (short for "release"):

$ uname -r
6.11.0-29-generic

$ cat /proc/version
Linux version 6.11.0-29-generic (buildd@lcy02-amd64-008) (gcc 13.3.0) #29 SMP PREEMPT_DYNAMIC ...

The first line is the kernel version you are running right now. The second, read from the special file /proc/version, adds who built it, with which compiler, and when. Notice you are reading the kernel by opening a file: that trick appears again and again below.

1.2 What the Kernel Actually Does

The kernel's job breaks down into a few big responsibilities. Every one of them is about sharing a limited resource safely between many programs at once:

No single application could do these jobs for itself without being able to interfere with every other application. Centralising them in one trusted program is the whole idea of an operating-system kernel.

1.3 Kernel Space and User Space

You will meet two phrases constantly: kernel space and user space. They name the two worlds the mode split creates. Kernel space is where the kernel and its drivers run, with full hardware access. User space is where every normal program runs, fenced off and asking for help. The boundary between them is crossed millions of times a second, and crossing it is exactly what a system call is:

USER SPACE     your shell, editor, browser, servers   (limited)
                          |
                          |   system call  (a guarded doorway)
                          v
KERNEL SPACE   scheduler, memory, drivers, filesystems (full power)
                          |
                          v
HARDWARE       CPU, RAM, disks, network, devices

Keep this picture in mind. Almost everything in the rest of this article is either something happening in kernel space, or a way for you, standing in user space, to look across the line and see what the kernel is doing.

1.4 The Two Great Illusions: Scheduling and Virtual Memory

Two of the kernel's jobs are worth singling out, because together they create the illusion that every program has the machine to itself.

The first is scheduling. Your machine runs far more programs than it has CPU cores, yet each one behaves as if it runs without interruption. The kernel achieves this by context switching: it lets one process run for a few milliseconds, saves its exact state, and hands the core to the next, hundreds of times a second. A scheduler decides the order, balancing fairness against responsiveness, and you can nudge a process's share with its nice value, a priority that runs from -20 (greedy) to 19 (generous):

$ nice -n 10 ./backup.sh     # start a job at low priority (short for "niceness")
$ renice -n 5 -p 1234        # lower the priority of a process already running

The second is virtual memory. Every process is handed its own private, continuous view of memory and thinks it owns the whole machine. The kernel maps those virtual addresses onto real RAM in small chunks called pages, pushes pages it does not need out to swap on disk, and uses any spare RAM as a page cache so recently read files come back instantly. This is why free memory on a healthy Linux box looks alarmingly low: the kernel is deliberately spending it as cache.

$ grep -E 'Cached|SwapTotal' /proc/meminfo   # page cache and swap size
Cached:         14711040 kB
SwapTotal:       8388604 kB

Neither illusion is something you switch on; both are always running, for every process, maintained by the kernel millions of times a second. The vm.swappiness setting you will meet later is one small dial on this second illusion.

3. A Short History

The Linux kernel began as a student's side project and grew into the most widely deployed piece of software in the world. Knowing that story explains several of its design choices.

The background is Unix, written at AT&T's Bell Labs from 1969, and its idea of a small kernel plus many small tools. Unix was not free, so in the 1980s two efforts set out to build a free replacement. Richard Stallman started the GNU project in 1983 and built a full set of Unix tools, but its own kernel was not ready. Separately, Andrew Tanenbaum wrote Minix, a small teaching operating system, so students could study a real kernel's source.

In 1991 a Finnish student, Linus Torvalds, frustrated with Minix's licence, started writing his own kernel for fun. His announcement on 25 August 1991 is famous for how modest it was:

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones." The hobby became the kernel that now runs most of the internet, all 500 of the Top 500 supercomputers, and every Android phone.

Torvalds released the kernel under the GNU GPL, so anyone could read, change, and share it. Combined with the already-finished GNU tools, it made a complete free operating system. Thousands of developers joined, and it grew into the largest collaborative software project ever.

One early argument shaped how people think about the kernel. In 1992 Tanenbaum publicly called Linux's monolithic design obsolete, arguing for a microkernel instead. In a monolithic kernel, drivers and filesystems all run together in kernel space; in a microkernel, most of them run as separate user-space programs. Linux stayed monolithic, for speed and simplicity, but added loadable modules so it did not have to be one rigid block. That "monolithic but modular" choice is still the design today.

The version numbers deserve a note, because they surprise people. Since the 3.0 jump, the first number does not mean a major rewrite; Torvalds raises it mostly when the second number grows uncomfortably large. A new stable kernel now comes out roughly every nine or ten weeks. The version you run, such as 6.11, is just a point on a steady, continuous line.

Not every release is meant to be kept, and the difference matters when you choose a kernel. Most versions are stable releases, maintained for only a couple of months. A few are marked Long-Term Support (LTS) and receive security fixes for several years; these are the ones distributions build on and almost every production server runs. Above them sits the mainline, where Torvalds merges new development. In practice you almost never chase the newest mainline kernel: you run the tested LTS kernel your distribution ships and let it feed you the security patches.

5. Moderate Use Cases

Once you can read the kernel, the next step is to watch it work and to see the parts it loads on demand. None of this changes anything; it is all inspection, and most of it needs no special rights.

5.1 Kernel Modules: The Parts That Load on Demand

A module is a piece of kernel code, most often a device driver, that can be loaded into the running kernel and unloaded again without a reboot. This is how one small kernel file supports thousands of different devices: it loads only the drivers your hardware actually needs. List the loaded ones with lsmod ("list modules"):

$ lsmod | head -4
Module                  Size  Used by
tls                   155648  0
inet_diag              28672  2 tcp_diag,udp_diag
udp_diag               12288  0

Each row is a driver or feature living inside your kernel right now. To learn what one is, ask modinfo:

$ modinfo tls
filename:       /lib/modules/6.11.0-29-generic/kernel/net/tls/tls.ko.zst
license:        Dual BSD/GPL
description:    Transport Layer Security Support

The .ko in the filename stands for "kernel object", the format a module takes on disk. On modern systems it is compressed, hence the extra .zst. Loading and unloading modules needs root and is done with modprobe, which also pulls in any modules the one you ask for depends on:

$ sudo modprobe -r tls     # remove a module (short for "remove")
$ sudo modprobe tls        # load it again, with its dependencies

5.2 Reading the Kernel Through /proc and /sys

You already read /proc/version above. That file is not really on any disk: it is part of procfs, a virtual filesystem the kernel invents in memory to expose its own state as ordinary files. Its companion, sysfs at /sys, does the same for devices and kernel objects. Together they are the reason so much of Linux is inspected by simply reading a file:

$ cat /proc/cpuinfo        # every CPU core the kernel sees
$ cat /proc/meminfo        # memory totals, straight from the kernel
$ cat /proc/uptime         # seconds since the kernel started
$ ls /sys/class/net        # network interfaces the kernel knows about

Nothing here is a real file waiting on a disk. Every read is a live question to the kernel, answered on the spot. Tools like free, top, and lscpu are, underneath, just friendly readers of these same virtual files.

5.3 The Kernel's Own Log: dmesg

The kernel keeps a running log of its own messages in a memory area called the ring buffer: hardware it detected, drivers it loaded, errors it hit. You read it with dmesg ("display message"):

$ dmesg | head            # earliest boot messages: CPU, memory, devices
$ sudo dmesg -w           # follow new kernel messages live (short for "wait")
$ sudo dmesg -T           # show human-readable timestamps

This is the first place to look when hardware misbehaves. Plug in a USB drive and run dmesg, and you will see the kernel notice the device, load a driver, and name the new disk. On many distributions reading dmesg now needs sudo, because the log can reveal details useful to an attacker.

5.4 One Interface for Every Filesystem: the VFS

Linux reads an ext4 disk, an XFS disk, a Btrfs volume, a FAT USB stick, and a network share over NFS with the exact same commands. That is not luck. The kernel has a layer called the Virtual File System (VFS) that presents one common interface, so cd, ls, cp, and the open and read system calls behave identically no matter which real filesystem sits underneath. Each filesystem type simply plugs into the VFS. You can list every type your kernel currently understands in another virtual file:

$ cat /proc/filesystems     # filesystem types this kernel supports
nodev   sysfs
nodev   proc
        ext4
        xfs
        btrfs

The nodev marker means the type has no backing device, such as the virtual proc filesystem; the others are real on-disk formats. The VFS is why a Linux user rarely has to think about which filesystem they are on: the kernel hides the differences behind one uniform set of files, directories, and permissions.

7. Something Most Users Do Not Know

7.1 The Whole Kernel Is One Small File

It is easy to imagine the kernel as something vast and spread out. It is a single file of around fifteen megabytes in /boot, named vmlinuz. The name itself tells a story: vm because it supports virtual memory, linu for Linux, and a final z because the file is compressed. At boot the kernel unpacks itself into memory, and from then on that one modest file is in complete charge of a machine with gigabytes of RAM and dozens of devices. Everything else on disk is just programs and data that this one file will agree to run.

7.2 Almost Everything You Do Is a System Call

The strace example was a glimpse of a deeper truth: user-space programs cannot do anything real on their own. Printing text, creating a file, opening a network connection, starting another program, reading the clock, all of these are system calls, requests made to the kernel. There are only a few hundred of them, and that short list is the complete vocabulary in which every program on the system asks for anything. When you understand that a program is just a sequence of computations punctuated by syscalls, the whole machine stops being mysterious.

7.3 The Kernel Does Not "Run" Like a Program

You will never see the kernel in a list of processes, because it is not a process. It has no place in the ps output the way a service does. Instead the kernel sits idle until something calls into it: a program makes a system call, or a device raises an interrupt, and the CPU switches into kernel mode, runs the relevant kernel code, and switches back. The kernel is less a program that runs and more a body of code that is entered, does its work, and is left again, millions of times a second. That is why it can manage everything without ever appearing as a running task.

7.4 Modules Are Kernel Code Loaded While You Work

When you plug in a webcam and it simply works, the kernel has just loaded a driver into itself, live, without a reboot. That loadable driver is a module, and it runs with the same full power as the rest of the kernel; there is no safety fence between a module and the core once it is loaded. This is the payoff of the "monolithic but modular" design from the history section: the kernel stays small on disk by keeping the thousands of drivers it might need as separate module files, and pulling in only the ones your actual hardware asks for.

7.5 You Are Almost Certainly Running Several Kernels' Worth of Choices

Every kernel update leaves the previous kernel installed. Over time you accumulate a small stack of them in /boot and /lib/modules, and the boot menu quietly offers them all. This is a deliberate safety net, not clutter: if a new kernel fails to boot or breaks a driver, you reboot, pick the previous one from the menu, and you are working again in seconds. It is the single best reason kernel upgrades on Linux are so low-risk, and it is why clearing out old kernels is something to do carefully, keeping at least one known-good fallback.

7.6 "Linux" Is Only the Kernel

The thing this whole article describes, the kernel, is the only part that is strictly named Linux. The shell you type into, the ls and cat and grep commands, the compiler, the C library: none of those are Linux. They come mostly from GNU and other projects, and they are the same across many operating systems. Linux is the core they all sit on. That is why the careful name for the whole system is GNU/Linux, and why your kernel, asked its operating system with uname -o, answers with exactly that pair of names.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Deleting all old kernels to free space. Remove old versions carefully and always keep at least one previous kernel, or a failed upgrade can leave you with no way to boot.
• Making a sysctl change and expecting it to survive a reboot. A live change with -w is temporary. Write it into /etc/sysctl.d/ to make it permanent.
• Confusing kernel version with distribution version. Ubuntu 24.04 and the kernel 6.11 are two different things. uname -r gives the kernel; /etc/os-release gives the distribution.
• Compiling a custom kernel without a fallback. Always leave the working distribution kernel installed and in the boot menu, so a broken custom build is not a dead machine.
• Assuming the kernel logs to /var/log only. The kernel's own live buffer is dmesg. Text logs are written from it afterwards; the buffer is the source.
• Loading a module built for a different kernel. Modules are tied to the exact kernel version they were built for, which is why each kernel has its own /lib/modules directory.