Linux Kernel Module Cheat

38.13.1. Linux kernel build variants

If you want to keep two builds around, one for the latest Linux version, and the other for Linux v4.16:

# Build master.
./build-linux

# Build another branch.
git -C "$(./getvar linux_source_dir)" fetch --tags --unshallow
git -C "$(./getvar linux_source_dir)" checkout v4.16
./build-linux --linux-build-id v4.16

# Restore master.
git -C "$(./getvar linux_source_dir)" checkout -

# Run master.
./run

# Run another branch.
./run --linux-build-id v4.16

The git fetch --unshallow is needed the first time because ./build --download-dependencies only does a shallow clone of the Linux kernel to save space and time, see also: https://stackoverflow.com/questions/6802145/how-to-convert-a-git-shallow-clone-to-a-full-clone

The --linux-build-id option should be passed to all scripts that support it, much like --arch for the CPU architecture, e.g. to step debug:

./run-gdb --linux-build-id v4.16

To run both kernels simultaneously, one on each QEMU instance, see: Section 38.12, “Simultaneous runs”.

You can also build Kernel modules against a specific prebuilt kernel with:

./build-modules --linux-build-id v4.16

This will then allow you to insmod the kernel modules on your newly built kernel.

Note that for this build to work the Linux kernel must remain checked out at the same version as it was built from, because the build dir which modules build against via the M= argument points to the absolute path of the Linux kernel source from which the headers are taken. For this reason, if you are going to be building kernel modules against a specific kernel version, it is a good idea to use a Linux worktree to ensure that the source for a build is always there.

Linux worktree