On Tue, Jul 30, 2024 at 06:10:55PM +0800, David Gow wrote: > On Mon, 29 Jul 2024 at 22:09, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > > > > > > > On 7/29/24 1:07 AM, Muhammad Usama Anjum wrote: > > > On 7/27/24 10:35 PM, Yury Norov wrote: > > >> On Fri, Jul 26, 2024 at 04:06:57PM +0500, Muhammad Usama Anjum wrote: > > >>> Rename module to bitmap_kunit and rename the configuration option > > >>> compliant with kunit framework. > > >> > > >> ... , so those enabling bitmaps testing in their configs by setting > > >> "CONFIG_TEST_BITMAP=y" will suddenly get it broken, and will likely > > >> not realize it until something nasty will happen. > > > CONFIG_TEST_BITMAP was being enabled by the kselftest suite lib. The bitmap > > > test and its config option would disappear. The same test can be run by > > > just enabling KUNIT default config option: > > > > > > KUNIT_ALL_TESTS=y enables this bitmap config by default. > > > > > >> > > >> Sorry, NAK for config rename. > > >> > > > > I agree with Yury. Using KUNIT takes away test coverage for people who > > are willing to run selftests but not use KUNIT. > > I can see the point that renaming the config option is just churn, but > is there a reason people would run the bitmap selftest but be unable > or unwilling to use KUnit? > > Beyond a brief period of adjustment (which could probably be made > quite minimal with a wrapper script or something), there shouldn't > really be any fundamental difference: KUnit tests can already run at > boot, be configured with a config option, and write output to the > kernel log. There's nothing really being taken away here, and the > bonus of having easier access to run the tests with KUnit's tooling > (or have them automatically run by systems which run KUnit tests) > would seem worthwhile to me, especially since it's optional. And > CONFIG_KUNIT shouldn't be heavy enough to cause problems. > > Obviously I can't force people to use KUnit, but this is exactly the > sort of test which would fit KUnit well, and -- forgive me if I'm > missing something -- the only real argument against it I'm hearing is > "it's different". And while that's valid (as I said, churn for churn's > sake isn't great), none of the "people who are willing to run > selftests but not use KUnit" have given reasons why. Especially since > this is the sort of test (testing in-kernel functions) we're > encouraging people to write with KUnit in > Documentation/dev-tools/testing-overview.rst -- if there are good > reasons people are refusing to run these, maybe we need to fix those > or change the recommendation. This doesn't work like this, and never did. Against every change of that sort there's always a strong, valid and self-contained argument: don't touch something that works. However, reviewers provided more than one reason against this rework. Every person has their own reasoning. For me it's history wipe and change of a method how we enable the test. For John, Shuah, Randy and others there's a bunch of other reasons. And my question is still unanswered: what exactly is getting better with this switch to KUNIT, comparing to the old behavior?
