mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-27 20:14:27 +01:00
buildroot: remove all default guest packages to make image tiny
This commit is contained in:
Ciro Santilli 六四事件 法轮功
104
README.adoc
104
README.adoc
@@ -98,7 +98,7 @@ see this: https://askubuntu.com/questions/496549/error-you-must-put-some-source-
|
||||
|
||||
It does not work if you just download the `.zip` from GitHub because we use link:.gitmodules[Git submodules], you must clone this repo. `./configure` then fetches only the required submodules for you.
|
||||
|
||||
After QEMU opens up, you can start playing with the kernel modules:
|
||||
QEMU opens up and you can start playing with the kernel modules inside the simulated system:
|
||||
|
||||
....
|
||||
insmod /hello.ko
|
||||
@@ -216,12 +216,18 @@ and then rebuild the kernel modules and re-run to see it take effect:
|
||||
|
||||
Congratulations, you are now officially a kernel module hacker!
|
||||
|
||||
We use `./build-buildroot` here because kernel modules go into the root filesystem, and it is Buildroot that generates our root filesystem. The kernel modules are inside a Buildroot package.
|
||||
We use `./build-buildroot` because the kernel modules go inside the root filesystem, and it is Buildroot that generates and updates our root filesystem. The kernel modules are link:packages/kernel_modules[inside a Buildroot package].
|
||||
|
||||
`--kernel-modules` is required even if files were modified as explained at: <<rebuild-buildroot-packages>>.
|
||||
`--kernel-modules` is required for the rebuild even though files were modified as explained at: <<rebuild-buildroot-packages>>.
|
||||
|
||||
The reboot after rebuild is annoying. We don't have a perfect solution for it yet, but there are some ideas cooking at: <<gem5-restore-new-script>>.
|
||||
|
||||
Using <<KVM>> can speed boot up however if your host and guest have the same arch, e.g. on an `x86_64` host:
|
||||
|
||||
....
|
||||
./run --kvm
|
||||
....
|
||||
|
||||
Not satisfied with kernel modules? OK then, let's hack up the <<linux-kernel-entry-point,entry point of the>> Linux kernel itself.
|
||||
|
||||
Open the file:
|
||||
@@ -1405,7 +1411,11 @@ The number of cores is modified as explained at: <<number-of-cores>>
|
||||
`taskset` from the util-linux package sets the initial core affinity of a program:
|
||||
|
||||
....
|
||||
taskset -c 1,1 /sched_getaffinity.out
|
||||
./build-buildroot \
|
||||
--buildroot-config 'BR2_PACKAGE_UTIL_LINUX=y' \
|
||||
--buildroot-config 'BR2_PACKAGE_UTIL_LINUX_SCHEDUTILS=y' \
|
||||
;
|
||||
./run --eval-busybox 'taskset -c 1,1 /sched_getaffinity.out'
|
||||
....
|
||||
|
||||
output:
|
||||
@@ -1710,7 +1720,13 @@ But TODO I don't think you can see where you are in the kernel source code and l
|
||||
|
||||
Step debug userland processes to understand how they are talking to the kernel.
|
||||
|
||||
Guest:
|
||||
First build `gdbserver` into the root filesystem:
|
||||
|
||||
....
|
||||
./build-buildroot --buildroot-config 'BR2_PACKAGE_GDB=y'
|
||||
....
|
||||
|
||||
Then on guest:
|
||||
|
||||
....
|
||||
/gdbserver.sh /myinsmod.out /hello.ko
|
||||
@@ -2341,10 +2357,17 @@ Files that contain device trees have the `.dtb` extension when compiled, and `.d
|
||||
|
||||
You can convert between those formats with:
|
||||
|
||||
....
|
||||
"$(./getvar host_dir)"/bin/dtc -I dtb -O dts -o a.dts a.dtb
|
||||
"$(./getvar host_dir)"/bin/dtc -I dts -O dtb -o a.dtb a.dts
|
||||
....
|
||||
|
||||
Buildroot builds the tool due to `BR2_PACKAGE_HOST_DTC=y`.
|
||||
|
||||
On Ubuntu 18.04, the package is named:
|
||||
|
||||
....
|
||||
sudo apt-get install device-tree-compiler
|
||||
dtc -I dtb -O dts -o a.dts a.dtb
|
||||
dtc -I dts -O dtb -o a.dtb a.dts
|
||||
....
|
||||
|
||||
See also: https://stackoverflow.com/questions/14000736/tool-to-visualize-the-device-tree-file-dtb-used-by-the-linux-kernel/39931834#39931834
|
||||
@@ -2405,13 +2428,25 @@ then `dtc a.dts` gives:
|
||||
};
|
||||
....
|
||||
|
||||
=== Get device tree from running kernel
|
||||
=== Get device tree from a running kernel
|
||||
|
||||
https://unix.stackexchange.com/questions/265890/is-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running/330926#330926
|
||||
|
||||
This is specially interesting because QEMU and gem5 are capable of generating DTBs that match the selected machine depending on dynamic command line parameters for some types of machines.
|
||||
|
||||
QEMU's `-M virt` for example, which we use by default for `aarch64`, boots just fine without the `-dtb` option:
|
||||
So observing the device tree from the guest allows to easily see what the emulator has generated.
|
||||
|
||||
Compile the `dtc` tool into the root filesystem:
|
||||
|
||||
....
|
||||
./build-buildroot \
|
||||
--arch aarch64 \
|
||||
--buildroot-config 'BR2_PACKAGE_DTC=y' \
|
||||
--buildroot-config 'BR2_PACKAGE_DTC_PROGRAMS=y' \
|
||||
;
|
||||
....
|
||||
|
||||
`-M virt` for example, which we use by default for `aarch64`, boots just fine without the `-dtb` option:
|
||||
|
||||
....
|
||||
./run --arch aarch64
|
||||
@@ -5514,6 +5549,14 @@ Each `enable` under the `events/` tree enables a certain set of functions, the h
|
||||
|
||||
TODO: can you get function arguments? https://stackoverflow.com/questions/27608752/does-ftrace-allow-capture-of-system-call-arguments-to-the-linux-kernel-or-only
|
||||
|
||||
===== trace-cmd
|
||||
|
||||
TODO example:
|
||||
|
||||
....
|
||||
./build-buildroot --buildroot-config 'BR2_PACKAGE_TRACE_CMD=y'
|
||||
....
|
||||
|
||||
==== Kprobes
|
||||
|
||||
kprobes is an instrumentation mechanism that injects arbitrary code at a given address in a trap instruction, much like GDB. Oh, the good old kernel. :-)
|
||||
@@ -7843,7 +7886,13 @@ OK, this is why we used gem5 in the first place, performance measurements!
|
||||
|
||||
Let's see how many cycles https://en.wikipedia.org/wiki/Dhrystone[Dhrystone], which Buildroot provides, takes for a few different input parameters.
|
||||
|
||||
A flexible setup is demonstrated at:
|
||||
First build Dhrystone into the root filesystem:
|
||||
|
||||
....
|
||||
./build-buildroot --buildroot-config 'BR2_PACKAGE_DHRYSTONE=y'
|
||||
....
|
||||
|
||||
Then, a flexible setup is demonstrated at:
|
||||
|
||||
....
|
||||
./gem5-bench-dhrystone
|
||||
@@ -9219,20 +9268,11 @@ First, see if you can't get away without actually adding a new package, for exam
|
||||
* if you have a standalone C file with no dependencies besides the C standard library to be compiled with GCC, just add a new file under link:packages/kernel_modules/user[] and you are done
|
||||
* if you have a dependency on a library, first check if Buildroot doesn't have a package for it already with `ls buildroot/package`. If yes, just enable that package as explained at: <<custom-buildroot-configs>>
|
||||
|
||||
If none of those methods are flexible enough for you, create a new package as follows:
|
||||
If none of those methods are flexible enough for you, you can just fork or hack up link:packages/sample_package[] the sample package to do what you want.
|
||||
|
||||
* use link:packages/sample_package[] as a starting point
|
||||
* fork this repository, and modify that package to do what you want
|
||||
* read the comments on that package to get an idea of how to start
|
||||
* check the main manual for more complicated things: https://buildroot.org/downloads/manual/manual.html
|
||||
* don't forget to rebuild with:
|
||||
+
|
||||
....
|
||||
./build-buildroot -- sample_package-reconfigure
|
||||
./run --eval-busybox '/sample_package.out'
|
||||
....
|
||||
+
|
||||
if you make any changes to that package after the initial build: <<rebuild-buildroot-packages>>
|
||||
For how to use that package, see: <<packages-directory>>.
|
||||
|
||||
Then iterate trying to do what you want and reading the manual until it works: https://buildroot.org/downloads/manual/manual.html
|
||||
|
||||
=== BR2_TARGET_ROOTFS_EXT2_SIZE
|
||||
|
||||
@@ -9490,7 +9530,9 @@ xdg-open graph-size.pdf
|
||||
|
||||
Our philosophy is:
|
||||
|
||||
* keep the root filesystem as tiny as possible to make prebuilts small. It is easy to add new packages once you have the toolchain.
|
||||
* keep the root filesystem as tiny as possible to make <<prebuilt>> small: only add BusyBox to have a small interactive system.
|
||||
+
|
||||
It is easy to add new packages once you have the toolchain, and if you don't there are infinitely many packages to cover and we can't cover them all.
|
||||
* enable every feature possible on the toolchain (GCC, Binutils), because changes imply Buildroot rebuilds
|
||||
* runtime is sacred. Faster systems are:
|
||||
+
|
||||
@@ -10041,10 +10083,20 @@ Every directory inside it is a Buildroot package.
|
||||
Those packages get automatically added to Buildroot's `BR2_EXTERNAL`, so all you need to do is to turn them on during build, e.g.:
|
||||
|
||||
....
|
||||
./build-buildroot --buildroot-config BR2_SAMPLE_PACKAGE=y
|
||||
./build-buildroot --buildroot-config 'BR2_SAMPLE_PACKAGE=y'
|
||||
....
|
||||
|
||||
If you want to add something to the root filesystem, possibly involving cross-compilation, then packages are the way to go.
|
||||
or force a rebuild after the first one with:
|
||||
|
||||
....
|
||||
./build-buildroot --buildroot-config 'BR2_SAMPLE_PACKAGE=y' -- sample_package-reconfigure
|
||||
....
|
||||
|
||||
then test it out with:
|
||||
|
||||
....
|
||||
./run --eval-busybox '/sample_package.out'
|
||||
....
|
||||
|
||||
In particular, our kernel modules are stored inside a Buildroot package: link:packages/kernel_modules[].
|
||||
|
||||
|
||||
Reference in New Issue
Block a user