Possibly reduced coverage

Posted Jul 9, 2025 11:42 UTC (Wed) by metan (subscriber, #74107)
Parent article: Toward the unification of kselftests and KUnit

I would say that this partially defeats the purpose of the testing since one of the goals kernel testing has is to make sure that kernel works well together with order of magnitude more complex libc in user space. It's probably good enough for quick CI tests though.

Possibly reduced coverage

Posted Jul 9, 2025 13:33 UTC (Wed) by t-8ch (subscriber, #90907) [Link]

This framework is also capable of running full libc executables.
These will be larger and a full userspace toolchain is needed to build them.

Furthermore the existing kselftest framework won't go away. So test coverage should strictly increase.

Possibly reduced coverage

Posted Jul 10, 2025 14:38 UTC (Thu) by tbird20d (subscriber, #1901) [Link]

I agree with the concern here. To the degree that this adds (in net terms) to the test results pool, by making the use of kselftest easier, then this will be a good thing. But I do worry that this particular test configuration will miss a lot of code paths (in either the kernel or user space), that a more traditional (ie real-world) kselftest configuration would touch. Overall, if it catches bugs, it's most likely a net gain. I suspect that people who have already figured out how to overcome the obstacles to running kselftest that this patch set addresses are unlikely to back off and test in more limited configurations (which could potentially lead to less test coverage). But it's something to watch out for.