LWN: Comments on "Toward the unification of kselftests and KUnit"

What about the opposite?

jgg — Thu, 10 Jul 2025 17:20:52 +0000

tools/testing/kunit/kunit.py is great, I think it is really under appreciated!

A tradeoff in testing attributes

tbird20d — Thu, 10 Jul 2025 14:56:06 +0000

While it will be nice to make running kselftest easier, I hope this does not end up imposing requirements on test developers that make that aspect of the testing lifecycle harder. That is, right now you can write a kselftest as a simple shell script or a python program. A quick perusal of tools/testing/selftest shows that over 600 of the existing selftests are shell scripts. I would hope that introducing a new test configuration for kselftests does not introduce an incentive
to avoid wirting and using this kind of test.

Shell scripts have the entire set of user-space programs and libraries at their disposal. Often, they are just glue doing sequences of operations where the kernel access and interactions are done by the programs that would be used in real production environments. These will be hard to utilize without a full distribution in place (or some careful analysis to create a limited distribution), as well as needing a shell script interpreter inside the kernel.

It will be interesting to see how many existing kselftest tests will be amenable to being run in the limited environment of a kernel module.

Possibly reduced coverage

tbird20d — Thu, 10 Jul 2025 14:38:31 +0000

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.

Possibly reduced coverage

t-8ch — Wed, 09 Jul 2025 13:33:03 +0000

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

metan — Wed, 09 Jul 2025 11:42:00 +0000

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.

What about the opposite?

t-8ch — Wed, 09 Jul 2025 10:01:40 +0000

That is already supported by KUnit. Take a look at tools/testing/kunit/kunit.py.

What about the opposite?

kakashir — Wed, 09 Jul 2025 09:25:29 +0000

It's same to just run the code under developing + KUnit in a VM. I'm not sure your key point here, do it automatically ?

What about the opposite?

taladar — Wed, 09 Jul 2025 07:08:26 +0000

What about the opposite use-case? Is there a way to automatically run the kernel you are working on as a developer in a VM to run the KUnit tests easily without rebooting your development system all the time? Assuming you are working on some feature that doesn't require a specific bit of hardware of course or where the hardware could be exposed to the VM.