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!
