The Design and Implementation of the Anykernel and Rump Kernels

214
• We noticed that even in superficially identical setups, such as installations
of the same OS version in QEMU, different results could be produced. An
example case of such a scenario was a test involving rename() on a FAT file
system. In some setups the test would simply panic the kernel with the error
“stack size exceeded” [40]. It was very difficult to start to guess where the
error was based purely on this information.
To make it easier to find problems, we adjusted the ATF test tool to automatically
include a stack trace in the report in case the test case dumped a core.
Since a rump kernel runs as a regular application and a kernel panic causes
a regular core dump, no special support is required for extracting the kernel
stack trace. The contents of the test report which motivated this change are
presented in Figure 4.9. The tests are run against a production build of the
binaries with compiler optimizations turned on, and the stacktrace needs to
be examined with that in mind. The information from the stack trace allowed
us to fix an off-by-one buffer size problem in the FAT driver’s rename
routine 18 .
Low overhead
Here we do not look at any particular test case, but rather the NetBSD test suite
as a whole. The test suite in 5.99.48 contains a total of 2,053 cases. These test
cases bootstrap 911 rump kernels, with each test case using zero, one, or up to 16
rump kernels. Running the entire test suite in a NetBSD instance hosted in qemukvm
took 56 minutes on March 31st, 2011 [40]. For comparison, if we assume that
bootstrapping one virtualized OS for testing were to take 4 seconds, bootstrapping
911 instances would take over an hour; this overhead is more than what it took to
run the entire test suite.
18 revision 1.72 of sys/fs/msdosfs/msdosfs_vnops.c