On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote: > > If KUnit is added to the kernel, and a subsystem that I am submitting > code for has chosen to use KUnit instead of kselftest, then yes, I do > *have* to use KUnit if my submission needs to contain a test for the > code unless I want to convince the maintainer that somehow my case > is special and I prefer to use kselftest instead of KUnittest. That's going to be between you and the maintainer. Today, if you want to submit a substantive change to xfs or ext4, you're going to be asked to create test for that new feature using xfstests. It doesn't matter that xfstests isn't in the kernel --- if that's what is required by the maintainer. > > supposed to be a simple way to run a large number of small tests that > > for specific small components in a system. > > kselftest also supports running a subset of tests. That subset of tests > can also be a large number of small tests. There is nothing inherent > in KUnit vs kselftest in this regard, as far as I am aware. The big difference is that kselftests are driven by a C program that runs in userspace. Take a look at tools/testing/selftests/filesystem/dnotify_test.c it has a main(int argc, char *argv) function. In contrast, KUnit are fragments of C code which run in the kernel; not in userspace. This allows us to test internal functions inside complex file system (such as the block allocator in ext4) directly. This makes it *fundamentally* different from kselftest. Cheers, - Ted
