The Linux kernel

This chapter follows Linux distributions and Debian.

Applications never touch the CPU’s privileged instructions directly. They ask the Linux kernel to open files, send packets, map memory, and create processes. Understanding that boundary explains permissions errors, driver issues, container isolation, and why a “Linux server” is really kernel plus distribution userland.

Kernel space and user space

User space is where your shell, web server, and desktop apps run. Each process has virtual memory the kernel maps to physical RAM or swap. Kernel space runs with full hardware access: interrupt handlers, schedulers, filesystem implementations, and network stacks.

Crossing the boundary happens through system calls (read, write, fork, ioctl, and hundreds more). libc (glibc on Debian) wraps syscalls with familiar C APIs. When strace shows openat or mmap, you are watching those crossings.

flowchart TB
  subgraph user [User space]
    apps[Applications and daemons]
    libc[glibc and runtime]
  end
  subgraph kernel [Kernel space]
    sched[Scheduler]
    vfs[VFS and filesystems]
    net[Network stack]
    drivers[Device drivers]
  end
  apps --> libc
  libc -->|system calls| vfs
  libc --> sched
  libc --> net
  drivers --> hardware[Hardware]

On macOS, the XNU kernel mixes Mach and BSD pieces; on FreeBSD, one kernel tree serves the whole system. Linux stays one monolithic codebase with optional loadable modules—different packaging, same idea: one privileged core.

System calls and the stable boundary

System calls are the contract between distro versions for compiled binaries. Userland linked against glibc expects specific syscall semantics; glibc and the kernel maintain compatibility across stable Debian releases.

Tools for inspection on Debian:

1
uname -r
2
uname -a
3
dmesg | less

uname -r prints the running kernel release. dmesg shows kernel ring-buffer messages: driver probes, hardware errors, and boot-time firmware messages—often the first place to look when a device fails after an upgrade.

Monolithic kernel and loadable modules

Linux is monolithic: core subsystems (scheduling, VFS, networking) live in one address space for performance. Loadable kernel modules (.ko files) extend the kernel without rebuilding everything—typical for filesystems, VPN helpers, and hardware drivers.

Debian splits modules into packages such as linux-image-amd64 (bootable image) and matching headers for building out-of-tree modules. lsmod lists loaded modules; modprobe loads them by name when dependencies allow.

Scheduling and memory at a high level

The scheduler decides which runnable process uses a CPU core. Linux uses CFS (Completely Fair Scheduler) for normal tasks and real-time classes for low-latency workloads. You feel scheduling as responsiveness under load, not as a daily configuration task.

Memory management maps virtual pages, handles copy-on-write after fork, reclaims cache under pressure, and swaps cold pages to disk when swap is enabled. OOM killer terminates processes when memory is exhausted—a last resort visible in dmesg.

These subsystems interact with cgroups (resource limits for containers) and namespaces (isolated views of IDs and mounts). Linux security primitives returns to those pieces; Docker builds on the same kernel features—see Docker overview.

Kernel versions, LTS, and Debian packages

Upstream publishes mainline kernels frequently; longterm branches receive security fixes for years. Debian stable ships a tested kernel and backports critical fixes without jumping to every mainline version.

Administrators choose among:

• Distribution kernel (recommended on Debian): security team support, signed packages.
• Backports or testing kernels when newer hardware needs fresher drivers—trade stability for hardware enablement.

Major version bumps (5.x to 6.x) add features and deprecate old interfaces; release notes and dmesg warnings matter before fleet upgrades.

You now have the split: kernel handles hardware and syscalls; the distribution supplies init, packages, and policy. Booting Linux and systemd picks up at power-on: firmware, bootloader, initramfs, and PID 1.

The next chapter is Booting Linux and systemd.