LWN: Comments on "Toward the unification of kselftests and KUnit" https://lwn.net/Articles/1029077/ This is a special feed containing comments posted to the individual LWN article titled "Toward the unification of kselftests and KUnit". en-us Mon, 20 Oct 2025 05:00:34 +0000 Mon, 20 Oct 2025 05:00:34 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net What about the opposite? https://lwn.net/Articles/1029439/ https://lwn.net/Articles/1029439/ jgg <div class="FormattedComment"> tools/testing/kunit/kunit.py is great, I think it is really under appreciated!<br> </div> Thu, 10 Jul 2025 17:20:52 +0000 A tradeoff in testing attributes https://lwn.net/Articles/1029365/ https://lwn.net/Articles/1029365/ tbird20d <div class="FormattedComment"> 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<br> to avoid wirting and using this kind of test.<br> <p> 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.<br> <p> 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. <br> </div> Thu, 10 Jul 2025 14:56:06 +0000 Possibly reduced coverage https://lwn.net/Articles/1029363/ https://lwn.net/Articles/1029363/ tbird20d <div class="FormattedComment"> 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.<br> </div> Thu, 10 Jul 2025 14:38:31 +0000 Possibly reduced coverage https://lwn.net/Articles/1029279/ https://lwn.net/Articles/1029279/ t-8ch <div class="FormattedComment"> This framework is also capable of running full libc executables.<br> These will be larger and a full userspace toolchain is needed to build them.<br> <p> Furthermore the existing kselftest framework won't go away. So test coverage should strictly increase.<br> </div> Wed, 09 Jul 2025 13:33:03 +0000 Possibly reduced coverage https://lwn.net/Articles/1029211/ https://lwn.net/Articles/1029211/ metan <div class="FormattedComment"> 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.<br> </div> Wed, 09 Jul 2025 11:42:00 +0000 What about the opposite? https://lwn.net/Articles/1029215/ https://lwn.net/Articles/1029215/ t-8ch <div class="FormattedComment"> That is already supported by KUnit. Take a look at tools/testing/kunit/kunit.py.<br> </div> Wed, 09 Jul 2025 10:01:40 +0000 What about the opposite? https://lwn.net/Articles/1029213/ https://lwn.net/Articles/1029213/ kakashir <div class="FormattedComment"> 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 ?<br> </div> Wed, 09 Jul 2025 09:25:29 +0000 What about the opposite? https://lwn.net/Articles/1029207/ https://lwn.net/Articles/1029207/ taladar <div class="FormattedComment"> 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.<br> </div> Wed, 09 Jul 2025 07:08:26 +0000