The Linux Kernel Module Programming Guide

I've written a little bit about writing a driver & using QEMU to create a custom device for it at [0] & [1]

[0]: https://blog.davidv.dev/posts/learning-pcie/

[1]: https://blog.davidv.dev/posts/pcie-driver-dma/

virtme-ng https://github.com/arighi/virtme-ng makes it really easy to launch development kernels in qemu.

I use qemu extensively especially for early-stage kernel debugging when no console is available; one such was just this week with v6.8 where, on arm64, any kernel command-line parameter >= 146 characters hangs the kernel instantly and silently.

Here's how I used qemu + gdb (on Debian 12 Bookworm amd64 host) to emulate and execute the arm64 kernel build to single-step the problematic code to identify the cause.

1. In a prepared kernel build system (i.e; all build dependencies and cross-compile tools installed) build the kernel image. I do this in an unprivileged systemd-nspawn amd64 container to avoid messy -dev package installs on the host. Nspawn bind-mounts the host's source-code tree which includes a separate build directory:

  cd "${SRC_DIR}"
  # copy/install/configure a suitable ${BUILD_DIR}/.config; review/edit with:
  make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 4 menuconfig
  # build the kernel
  export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 12 Image
  # build gdb helper (Python) scripts 
  export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} scripts_gdb

2. Install "gdb" (and if doing foreign architecture debugging "gdb-multiarch") on the host as well as "qemu-system-arm"

3. Execute the kernel but -S[uspend] it and have QEMU listen for a connection from gdb:

  qemu-system-aarch64 -machine virt,gic-version=3 -cpu max,pauth-impdef=on -smp 2 -m 4096 -nographic -kernel ${BUILD_DIR}/arch/arm64/boot/Image -append "debug $( for l in {144..157}; do echo -n param$l=$(pwgen $((l-9)) 1)' '; done )" -initrd rootfs/boot/initrd.img-6.8.12-arm64-debug -S -gdb tcp::1234

4. In another terminal shell (I use "tmux" and create a new tmux window) start the debugger:

  cd ${BUILD_DIR}
  # this cd is important - gdb needs to be in the base of the BUILD directory
  gdb-multiarch ./vmlinux

  target remote :1234
  break __parse_cmdline
  continue

For more details on debugging kernel using gdb and the gdb scripts lx-* see

https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-...

Edit: Forgot to note that for gdb to be able to use the lx-* Python scripts it usually needs the path authorising:

  echo "add-auto-load-safe-path ${SRC_DIR}/scripts/gdb/vmlinux-gdb.py" > ~/.gdbinit

The wireguard test suite that’s now in the kernel is an excellent way to experiment with using qemu to develop kernel modules and also do automated tests.

I’d link but cumbersome to find on phone.

Greg KH said pretty explicitly there won’t be a 4th edition LDD

looks like a great TOC, sadly no preorder to support its creation :(

I'll grant that it's a bit of friction, but you can just run a compiler on the pi?

The proclivity to suggest something is LLM generated when it isn't is such a fun one. Almost like a Rorschach test for literary exposure.

The answer in this context is no (you've might not been exposed to enough fiction).

Why does it matter? My English is poor, so when I write long articles or posts, I ask GPT to fix errors. I do this because I respect my readers and don't want their eyes to bleed from reading my text.

Why would "Before delving into code..." be a red flag that marks the text as LLM-generated?

All I can't tell you is that it was already written this way in 2021: https://github.com/sysprog21/lkmpg/blob/2246e208093876de4c3b...

LLM likes to use "delve" doesn't mean every usages of "delve" imply LLM

I wouldn't think it matters as long as the [human] authors review it for accuracy.

Perfectly valid synonym for 'dive' in this context.