A previous post in this series showed how you can use the --bootargs parameter and .boot files to supply kernel boot parameters to the kernels under test. This works, but it turns out that there is another way, which is often the case with the Linux kernel. This other way is Masami Hiramatsu's bootconfig facility, which is nicely documented in detail here. This blog post is a how-to guide on making use of bootconfig when running rcutorture.
The bootconfig facility allows kernel boot parameters to be built into initrd or directly into the kernel itself, this last being the method used here. This requires that the kernel build system be informed of the parameters. Suppose that these parameters are placed in a file named /tmp/dump_tree.bootparam as follows:
kernel.rcutree.dump_tree=1
kernel.rcutree.blimit=15
Note well the "kernel." prefix, which is required here. The other option is an "init." prefix, which would cause the parameter to instead be passed to the init process.
Then the following three Kconfig options inform the build system of this file:
CONFIG_BOOT_CONFIG=y
CONFIG_BOOT_CONFIG_EMBED=y
CONFIG_BOOT_CONFIG_EMBED_FILE="/tmp/dump_tree.bootparam"
The resulting kernel image will then contain the above pair of kernel boot parameters. Except that you also have to tell the kernel to look for these parameters, which is done by passing in the "bootconfig" kernel boot parameter. And no, it does not work to add a "kernel.bootconfig" line to the /tmp/dump_tree.bootparam file! You can instead add it to a .boot file or to the kvm.sh command line like this: "--bootargs bootconfig".
For example, given this command:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 30s --configs TREE05 \
--bootargs "bootconfig" --trust-make
The resulting console.log file would contain the following text, indicating that these boot parameters had in fact been processed correctly, as indicated by the "Boot-time adjustment of callback invocation limit to 15." and the last three lines that begin with "rcu_node tree layout dump".
-----------
Running RCU self tests
rcu: Preemptible hierarchical RCU implementation.
rcu: CONFIG_RCU_FANOUT set to non-default value of 6.
rcu: RCU lockdep checking is enabled.
rcu: Build-time adjustment of leaf fanout to 6.
rcu: Boot-time adjustment of callback invocation limit to 15.
rcu: RCU debug GP pre-init slowdown 3 jiffies.
rcu: RCU debug GP init slowdown 3 jiffies.
rcu: RCU debug GP cleanup slowdown 3 jiffies.
Trampoline variant of Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
rcu: rcu_node tree layout dump
rcu: 0:7 ^0
rcu: 0:3 ^0 4:7 ^1
-----------
What happens if you use both CONFIG_BOOT_CONFIG_EMBED_FILE and the --bootargs parameter? The kernel boot parameters passed to --bootargs will be processed first, followed by those in /tmp/dump_tree.bootparam. Please note that the semantics of repeated kernel-boot parameters is subsystem-specific, so please also be careful.
The requirement that the "bootconfig" parameter be specified on the normal kernel command line can be an issue in environments where the this command line is not easily modified. One way of avoiding such issues is to create a Kconfig option that causes the kernel to act as if the "bootconfig" parameter had been specified. For example, the following -rcu commit does just this with a new CONFIG_BOOT_CONFIG_FORCE Kconfig option:
674b57ddd75e ("bootconfig: Allow forcing unconditional bootconfig processing")
It is important to note that although these embedded kernel-boot parameters show up at the beginning of the "/proc/cmdline" file, they may also be found in isolation in the "/proc/bootconfig" file, for example, like this:
$ cat /proc/bootconfig
kernel.rcutree.dump_tree = 1
kernel.rcutree.blimit = 15
Why do the embedded kernel-boot parameters show up at the beginning of "/proc/cmdline" instead of at the end, given that they are processed after the other parameters? Because of the possibility of a "--" in the non-embedded traditionally sourced kernel boot parameters, which would make it appear that the embedded kernel-boot parameters were intended for the init process rather than for the kernel.
But what is the point of all this?
Within the context of rcutorture, probably not much. But there are environments where external means of setting per-kernel-version kernel-boot parameters is inconvenient, and rcutorture is an easy way of testing the embedding of those parameters directly into the kernel image itself.