2.7. Host kernel module setup
THIS IS DANGEROUS (AND FUN), YOU HAVE BEEN WARNED
This method runs the kernel modules directly on your host computer without a VM, and saves you the compilation time and disk usage of the virtual machine method.
It has however severe limitations:
-
can’t control which kernel version and build options to use. So some of the modules will likely not compile because of kernel API changes, since the Linux kernel does not have a stable kernel module API.
-
bugs can easily break you system. E.g.:
-
segfaults can trivially lead to a kernel crash, and require a reboot
-
your disk could get erased. Yes, this can also happen with
sudo
from userland. But you should not usesudo
when developing newbie programs. And for the kernel you don’t have the choice not to usesudo
. -
even more subtle system corruption such as not being able to rmmod
-
-
can’t control which hardware is used, notably the CPU architecture
-
can’t step debug it with GDB easily. The alternatives are JTAG or KGDB, but those are less reliable, and require extra hardware.
Still interested?
./build-modules --host
Compilation will likely fail for some modules because of kernel or toolchain differences that we can’t control on the host.
The best workaround is to compile just your modules with:
./build-modules --host -- hello hello2
which is equivalent to:
./build-modules \ --gcc-which host \ --host \ -- \ kernel_modules/hello.c \ kernel_modules/hello2.c \ ;
Or just remove the .c
extension from the failing files and try again:
cd "$(./getvar kernel_modules_source_dir)" mv broken.c broken.c~
Once you manage to compile, and have come to terms with the fact that this may blow up your host, try it out with:
cd "$(./getvar kernel_modules_build_host_subdir)" sudo insmod hello.ko # Our module is there. sudo lsmod | grep hello # Last message should be: hello init dmesg -T sudo rmmod hello # Last message should be: hello exit dmesg -T # Not present anymore sudo lsmod | grep hello