Linux Kernel Programming 2E: the code and errata behind a kernel module book

A book repository that publishes its own corrections

This repository is the code for Linux Kernel Programming, Second Edition, published by Packt, written by Kaiwan N. Billimoria. What makes it more useful than a typical book code dump is the Known Errata section, which lists page-by-page corrections and keeps accumulating them.

The entries are specific in a way that tells you the author is actually running the code. On page 34 the fix is to replace `$ cat Kconfig` with `$ cat Kbuild`, which is the sort of detail that only surfaces when you type the command and it does not do what the book says. On page 166, `ccflags-y` was written as `ccflags_y` in three places, with a sed-style one-liner given to fix it. On page 197, the cross-compilation command shown for a 32-bit build was the wrong one, and the correct command for a 64-bit ARM build is given instead.

The page 85 and 86 entry is the most useful of the set, because it describes a real behaviour that has changed under people's feet rather than a typo. The book says modules always have a .ko suffix, and the errata explains that a config setting can force module compression, typically via ZSTD, which makes the file `foo.ko.zst` instead of `foo.ko`, and that this compression was added from Linux 5.13, with some distributions enabling it by default. It then says how to turn it off, through `make menuconfig`, under Enable loadable module support and Module compression mode, set to None.

The errata also records fixes to diagrams, with Figure 13.13 and 13.14 needing the RCU reader's arrow repointed to `new_ptr_x`, and two figure labels in chapter 12 corrected from one task identifier to another.

The code is written against the 6.1 LTS kernel

The book uses the 6.1 Long-Term Support kernel series, and the README explains why that choice should age well. The 6.1 series is maintained until December 2026, and the Civil Infrastructure Project has pledged to maintain and support the 6.1 Super LTS kernel until August 2033.

That is a specific and unusual claim about the longevity of the book, and it is worth taking at face value while noting what it means in practice. The book teaches the 6.x kernel API, and the module code in this repository is written against that API. A kernel that changes its internal interfaces between major versions will break that code, and while 6.1 itself is supported for years, the 6.x series as a moving target is a separate question from whether 6.1 specifically is maintained.

The chapter list shows how the book is organised. It opens with a quick introduction, then two chapters on building the 6.x Linux kernel from source, two on writing a first kernel module, then kernel internals on processes and threads, memory management internals, two chapters on kernel memory allocation for module authors, two on the CPU scheduler, and two on kernel synchronization. The key takeaways list names the same arc: configure and build the 6.1 LTS kernel from source, write modular kernel code with the LKM framework, work with the dynamic kernel memory allocation APIs, understand CPU scheduling including cgroups v2, and learn the synchronization primitives.

The synchronization half is the part with the most distinct list of technologies, naming mutexes, spinlocks, atomic and refcount operators, rw-spinlocks, and lock-free approaches such as per-CPU and RCU. That breadth is the reason the book is worth the repository, since those are the mechanisms where a beginner's code silently goes wrong.

The directory layout maps directly onto the chapter numbers

The top level of the repository is a chapter index, and it is organised so that you can find the code for what you are reading without a search.

Each chapter has two directories, one named for the chapter slug and one for the short number. So `ch1-intro` sits beside `ch1/`, `ch2-building_the_6.x_linux_kernel_from_source-part1` beside `ch2/`, and the same pattern continues through `ch13-kernel_synchronization-part2` beside `ch13/`. The numbered directories are where the code for that chapter lives, and the descriptive directories hold the accompanying files for that chapter.

Alongside the chapter directories there are four support areas that are not tied to a single chapter. `convenient.h`, `klib.c` and `klib.h` are shared helper code that the module examples build on, which is a sensible way to keep the sample modules short enough to read. The `lkm/` directory holds Loadable Kernel Module code, `test_lkm/` holds test modules, `questions/` and `solutions_to_assgn/` hold the assignments with answers, and `Further_Reading.md` collects pointers.

The primary language of the repository is recorded as Makefile, which tells you the build system for the samples is a plain Makefile rather than the kbuild system of the kernel tree itself, although the errata about Kbuild and Kconfig shows that the book does teach kernel build internals, since the module sources still have to be built the way the kernel expects when they are dropped into a kernel tree.

The platforms the code was actually tested on

The README includes a software and hardware list, and it is worth reading because it tells you exactly where the sample code was exercised and where it was not.

The developed and tested platforms are x86_64 Ubuntu 22.04 LTS and x86_64 Ubuntu 23.04 LTS, each used both as a native system and as a guest OS, x86_64 Fedora 38 and 39 again native and as a guest, and the ARM Raspberry Pi 4 Model B in 64-bit form, running both its own distro kernel and the custom 6.1 kernel the book builds, with that ARM configuration described as lightly tested.

The guest machines all ran on the host Oracle VirtualBox 7.0 hypervisor, so the build-from-source and module-loading exercises were done with the target system virtualised. That is a practically useful detail, because building a kernel natively on a distribution whose own kernel you are replacing is a riskier first experiment than doing it in a virtual machine.

The licence is MIT, with a `LICENSE` file in the tree, so the code can be reused, modified and redistributed with the notice retained. That matters more for a book repository than it might appear, since the sample modules are the parts a reader is most likely to lift into their own work.

The book itself is sold through Packt, with the product page linked from the README, and the first chapter is available as a free online PDF.

What the book is trying to be, and what it is not

The README describes the second edition as an updated guide for new programmers to the Linux kernel, and it is explicit about its editorial stance. The book deliberately moves away from bland and generic operating system theory and instead covers those topics where they are required, from the clear and distilled viewpoint of implementation details in a real, live operating system.

That is a defensible position and a common complaint about kernel books is that they spend two hundred pages on scheduling theory and then a hundred pages of module code. This one reverses the order, teaching the build and the module first and pulling in the internals as they become necessary.

The claimed outcome is that a reader ends up with an understanding of the fundamentals of writing the Linux kernel and kernel module code that can be used in real projects and products, which is a stronger claim than most books make, and one that the errata list both supports and complicates. Supporting, because the corrections are the kind that only appear when the code is actually run. Complicating, because the fixes themselves show how much of the surface is version-dependent.

The audience is stated as programmers new to kernel development as well as experienced developers, with a judicious mix of theory and practice and more focus on practical aspects.

What this repository is not is a kernel source mirror or a maintained driver collection. It is the sample code that accompanies a book, and it will drift out of step with any kernel release that changes the APIs the modules touch.

The right alternative depends on what you are actually trying to do

If the goal is to learn kernel module development, the real alternatives are the kernel documentation in the source tree and the kernel newbies mailing list archives, and the difference in approach is instructive. The in-tree documentation is written by the subsystem maintainers and is tied to the current API, so it is always accurate and always incomplete as a narrative. The mailing list archives contain the real reasoning behind design decisions, written in the terse style of people who have debugged the same problem three times. Neither of them gives you a buildable progression from your first module to a working synchronisation primitive.

This book and its repository give you that progression, with a stated target kernel, a tested platform list, and code you can compile. The cost is that it is a snapshot with a publication date, and the errata list is the mechanism by which the authors tell you where the snapshot is wrong.

If the goal instead is to solve a specific kernel problem, the ordering of the advice is different. The kernel source for your running version, with its Documentation directory, is the authority, and a book written against 6.1 is a secondary source at best. The cgroups v2 chapter and the RCU discussion are the parts most likely to have moved on.

One more limit is worth stating plainly. The repository covers the 6.x series and the code is written against it. A reader on a 6.12 or later kernel who copies a module from `ch8/` or `ch9/` may find the memory allocation APIs or the module loading interface have shifted, and nothing in the repository tells you where the boundary is. The errata file is the place to look first, since that is where the author records exactly this kind of drift.

Editorial conclusion

Adopt this repository if you are learning kernel module development and want the sample modules, the build scripts and the corrected errata alongside the text, since the errata file is a genuine service that a book repository rarely provides. Do not adopt it as a kernel source tree or as a reference for kernel internals beyond the 6.1 series, and do not expect the code to be current for recent kernel releases. Before you rely on it, check the `solutions_to_assgn/` and `questions/` directories to see how much of the assignment content is present, read the errata entries for the chapter you are working through, and confirm that your host kernel matches the 6.x series the book targets, since the code is written against that API and the 6.1 kernel is the one the book follows.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PacktPublishing/Linux-Kernel-Programming_2E on GitHub
4. README