On Wed, Jul 21, 2021 at 01:32:41PM +0200, Greg KH wrote: > On Fri, Jul 02, 2021 at 05:46:29PM -0700, Luis Chamberlain wrote: > > This selftests will shortly be expanded upon with more tests which > > require further kernel changes in order to provide better test > > coverage. > > Why is this not using kunit? We should not be adding new in-kernel > tests that are not using that api anymore. No way. That cannot possibly be true. When was this decided? Did Shuah Khan, the maintainer of selftests, all of a sudden decide we are going to deprecate selftests in favor for trying to only use kunit? Did we have a conference where this was talked about and decided? If so all these are huge news to me and I missed the memo! If I would have been at such meeting I would have definitely yelled bloody murder! kunit relies on UML and UML is a simple one core architecture, to start with. This means I cannot run tests for multicore with it, which is where many races do happen! Yes, you can run kunit on other architectures, but all that is new. Second, I did help review kunit getting upstream, and suggested a few example tests, part of which were for sysctl to compare and contrast what is possible and what we cannot do. Not everything we want to test should be written as a kunit test. No way. In this case kunit is not ideal given I want to mimic something in userspace interaction, and expose races through error injection and if we can use as many cores to busy races out. Trust me, I'm an advocate of kunit, and I'm even trying to see ideally what tests from fstests / blktests could be kunit'ified. But in this case, no. Using a selftests is much better target framework. > > diff --git a/lib/test_sysfs.c b/lib/test_sysfs.c > > new file mode 100644 > > index 000000000000..bf43016d40b5 > > --- /dev/null > > +++ b/lib/test_sysfs.c > > @@ -0,0 +1,943 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > This does not match your "boiler-plate" text below, sorry. Indeed, I'll fix it. Luis
