On 5/8/19 6:58 PM, Theodore Ts'o wrote: > On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote: >> kselftest provides a mechanism for in-kernel tests via modules. For >> example, see: >> >> tools/testing/selftests/vm/run_vmtests invokes: >> tools/testing/selftests/vm/test_vmalloc.sh >> loads module: >> test_vmalloc >> (which is built from lib/test_vmalloc.c if CONFIG_TEST_VMALLOC) > > The majority of the kselftests are implemented as userspace programs. Non-argument. > You *can* run in-kernel test using modules; but there is no framework > for the in-kernel code found in the test modules, which means each of > the in-kernel code has to create their own in-kernel test > infrastructure. Why create an entire new subsystem (KUnit) when you can add a header file (and .c code as appropriate) that outputs the proper TAP formatted results from kselftest kernel test modules? There are already a multitude of in kernel test modules used by kselftest. It would be good if they all used a common TAP compliant mechanism to report results. > That's much like saying you can use vice grips to turn a nut or > bolt-head. You *can*, but it might be that using a monkey wrench > would be a much better tool that is much easier. > > What would you say to a wood worker objecting that a toolbox should > contain a monkey wrench because he already knows how to use vise > grips, and his tiny brain shouldn't be forced to learn how to use a > wrench when he knows how to use a vise grip, which is a perfectly good > tool? > > If you want to use vice grips as a hammer, screwdriver, monkey wrench, > etc. there's nothing stopping you from doing that. But it's not fair > to object to other people who might want to use better tools. > > The reality is that we have a lot of testing tools. It's not just > kselftests. There is xfstests for file system code, blktests for > block layer tests, etc. We use the right tool for the right job. More specious arguments. -Frank > > - Ted >
