2.2.2.2. Your first kernel module hack
Edit kernel_modules/hello.c to contain:
pr_info("hello init hacked\n");
and rebuild with:
./build-modules
Now there are two ways to test it out: the fast way, and the safe way.
The fast way is, without quitting or rebooting QEMU, just directly re-insert the module with:
insmod /mnt/9p/out_rootfs_overlay/lkmc/hello.ko
and the new pr_info
message should now show on the terminal at the end of the boot.
This works because we have a 9P mount there setup by default, which mounts the host directory that contains the build outputs on the guest:
ls "$(./getvar out_rootfs_overlay_dir)"
The fast method is slightly risky because your previously insmodded buggy kernel module attempt might have corrupted the kernel memory, which could affect future runs.
Such failures are however unlikely, and you should be fine if you don’t see anything weird happening.
The safe way, is to fist quit QEMU, rebuild the modules, put them in the root filesystem, and then reboot:
./build-modules ./build-buildroot ./run --eval-after 'insmod hello.ko'
./build-buildroot
is required after ./build-modules
because it re-generates the root filesystem with the modules that we compiled at ./build-modules
.
You can see that ./build
does that as well, by running:
./build --dry-run
See also: Dry run to get commands for your project.
--eval-after
is optional: you could just type insmod hello.ko
in the terminal, but this makes it run automatically at the end of boot, and then drops you into a shell.
If the guest and host are the same arch, typically x86_64, you can speed up boot further with KVM:
./run --kvm
All of this put together makes the safe procedure acceptably fast for regular development as well.
It is also easy to GDB step debug kernel modules with our setup, see: Section 3.4, “GDB step debug kernel module”.