There are a number of tools available for writing tests in the kernel. One
of them is kselftest, which is a system for writing end-to-end tests. Another
is KUnit, which runs unit tests directly in the kernel.
These testing tools are very useful, but they lack the ability for maintainers
to configure how the tests should be run. For example, patches submitted to the
RCU tree and branch should run a quick subset of the full gamut of rcutorture
tests, whereas it is prudent to run heavyweight and comprehensive rcutorture
tests ~once / day on the linux-rcu tree, as well as various mainline trees,
etc. Similarly, cgroup tests can be run on every patch sent to the cgroup tree, but
certain testcases have known flakiness that could be signaled by the developer.
Maintainers and contributors would benefit from being able to configure their test
suites to illustrate the intent of individual testcases, and the suite at large, to
signal both to contributors and to CI systems, how the tests should be run and
interpreted. This MC discussion would ask the question of whether we should implement
this, and if so, what it would look like.
- Updating kernel test subsystem structure (ksefltest, kunit) to allow maintainers to express configurations for test suites. The idea here is to avoid developers having to include patches to each separate CI system to include and configure their test, and instead have all of that located in configuration files that are included in the test suite, with CI systems consuming and using this information as necessary.
- Discuss whether we should bring xfstests into the kernel source tree, and whether we could make it a kselftest.
- Discuss whether we can and should include coverage information in KernelCI.
- Guillaume Tucker and other KernelCI maintainers
- Ideally Shuah Khan as kselftest maintainer, and Brendan Higgins as KUnit maintainer
- Anyone interested in testing / CI signal (Thorsten Leemhuis perhaps, given his KR talk about how to submit an actionable kernel bug report?)
|I agree to abide by the anti-harassment policy||Yes|