3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-28 12:34:26 +01:00
Code Issues Releases Wiki Activity

docs: document slightly faster kernel module test setup

Browse Source
This commit is contained in:
Ciro Santilli
2025-04-28 13:40:14 +01:00
parent 4ba9d370db
commit e183476308
1 changed files with 8 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
README.adoc
View File

@@ -348,7 +348,7 @@ The fast method is slightly risky because your previously insmodded buggy kernel
Such failures are however unlikely, and you should be fine if you don't see anything weird happening. Such failures are however unlikely, and you should be fine if you don't see anything weird happening.
The safe way, is to fist <<rebuild-buildroot-while-running,quit QEMU>>, rebuild the modules, put them in the root filesystem, and then reboot: The safe way is to fist <<rebuild-buildroot-while-running,quit QEMU>>, rebuild the modules put them somewhere QEMU can see and then reboot. So you could either place it in the root filesystem:
.... ....
./build-modules ./build-modules
@@ -356,6 +356,13 @@ The safe way, is to fist <<rebuild-buildroot-while-running,quit QEMU>>, rebuild
./run --eval-after 'insmod hello.ko' ./run --eval-after 'insmod hello.ko'
.... ....
or for a slightly faster turnaround just leave it on 9p and use it from there:
....
./build-modules
./run --eval-after 'insmod /mnt/9p/out_rootfs_overlay/lkmc/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`. `./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: You can see that `./build` does that as well, by running: