On Thu, Jul 17, 2025 at 10:48:02AM +0200, Thomas Weißschuh wrote:
Currently testing of userspace and in-kernel API use two different frameworks.
Which is kinda expected as one has to run in the kernel to test in-kernel kernel space APIs, and the other tests externally provided kernel functionality.
Therefore kunit is much easier to run against different kernel configurations and architectures.
Which is is normal. unit tests are always easier to run than integration tests.
This series aims to combine kselftests and kunit, avoiding both their limitations. It works by compiling the userspace kselftests as part of the regular kernel build, embedding them into the kunit kernel or module and executing them from there.
This is really weird. "Running userspace code is hard, so we package it in the kernel". I had my own fair share of problems with kselftests, mostly because of the lack of structure and automated way to run them, but adding them to the kernel (or a module) is overshooting the target by far.
If the kernel toolchain is not fit to produce userspace because of a missing libc, the kernel's own nolibc can be used instead.
Is nolibc enough to run all the selftests? If so we should just do it unconditionally, but linking to different libraries by availability seems a bit problematic.
The structured TAP output from the kselftest is integrated into the kunit KTAP output transparently, the kunit parser can parse the combined logs together.
Good idea!