![]() The last ktest-specific bit of setup is to provide a custom, named boot entry in the GRUB menu. It's assumed that the VM is set up for passwordless ssh/ scp access for the root user, uses the grub2 bootloader, and has a tool to pick the kernel to reboot into such as grub2-reboot (called grub-reboot on some Linux distributions). The steps to install and configure a virsh VM are outside the scope of this post, but there are numerous resources that document this process. If you only want to run build tests, you can skip the section on VM assumptions. Here's an example showing how to build, boot, and run a test script for each patch in a series on a virsh VM. For boot testing, the host needs to be able to powercycle the target and read its console. ![]() Ktest is run from the host system and drives the target system remotely, typically via passwordless ssh/ scp if using a VM. ktest of course needs access to a Linux source tree and a directory to build the kernel(s) being tested. ![]() The idea is for this script to work on a small scale, so only two systems, host and target, are required. It starts with the good config, compares the options between the two configs, and changes half the differing options in the good config to match the bad, repeating the process until the culprit is found. Second, ktest can bisect between good and bad kernel configurations to find the option that's causing a problem. You can configure it to skip commits that encounter problems unrelated to the one you're looking for but that prevent testing for it, an unfortunately common thing when bisecting. Sometimes bugs aren't 100% reproducible, so ktest can try a given commit multiple times before moving on. First, it can do patch bisection to find either the first bad commit where something broke or the first good commit when something started working again (reverse bisection). In addition to the main build/boot/script testing, ktest can automate bisection in a couple of ways. Multiple tests can be specified at once, with default options optionally shared between them, allowing you to kick off a ktest session on different branches and kernel configs in one command. Ktest comes with numerous, battle-hardened configuration options allowing you to control, for example, compile options, kernel configuration, bootloader type, kernel install method, iterations, timeout lengths, power cycle command, and test success criteria. (Those bots are nice for less common configs though.) Code reviewers' moods improve too because each patch will stand alone with all the necessary code. For your chosen configs, the series will be cleanly bisectable and won't trigger upstream build bots with easily avoided errors and warnings mid-series. Where ktest is especially useful, though, is in its ability to do these things for each patch in a series, thereby freeing you from a significant amount of tedium. It can test multiple kernel configurations, in case the code you're touching is sensitive to that, and multiple architectures, in case you want to automate cross-compilation. See /home/penguin/src/ktest/log.ktest for more info. Warning: symbol 'totalcma_pages' was not declared. ![]() ![]() home/penguin/kernel/worktrees/ktest-blog/mm/page_alloc.c:135:15: For instance, here's ktest flagging a new warning during a build:ĬRITICAL FAILURE. The script can detect build failures, newly introduced warnings, runtime hangs and splats, and script failures. It's up to you how far in the process ktest will go, so it's possible to build, or build and boot, or do all three steps. Ktest can build a kernel on a host system, boot it on a target machine, and run a script on the target. This post will cover ktest's capabilities and requirements, and give concrete examples of how to use it in one specific environment, a single physical machine with a qemu VM run under virsh. The script is aimed at individual kernel programmers testing their patch series, and provides an alternative to the Autotest framework, which is powerful but quite involved for one person to set up. In October 2010, Steven Rostedt announced on the LKML that he was working on a script called to automate certain aspects of Linux kernel testing. Ktest: Automated Testing For Kernel Programmers ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |