On Thu, May 09, 2019 at 10:11:01PM -0700, Frank Rowand wrote: > >> 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. > > The kselftest in-kernel tests follow a common pattern. As such, there > is a framework. So we may have different definitions of "framework". In my book, code reuse by "cut and paste" does not make a framework. Could they be rewritten to *use* a framework, whether it be KTF or KUnit? Sure! But they are not using a framework *today*. > This next two paragraphs you ignored entirely in your reply: > > > 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? And you keep ignoring my main observation, which is that spinning up a VM, letting systemd start, mounting a root file system, etc., is all unnecessary overhead which takes time. This is important to me, because developer velocity is extremely important if you are doing test driven development. Yes, you can manually unload a module, recompile the module, somehow get the module back into the VM (perhaps by using virtio-9p), and then reloading the module with the in-kernel test code, and the restart the test. BUT: (a) even if it is faster, it requires a lot of manual steps, and would be very hard to automate, and (b) if the test code ever OOPS or triggers a lockdep warning, you will need to restart the VM, and so this involves all of the VM restart overhead, plus trying to automate determining when you actually do need to restart the VM versus unloading and reloading the module. It's clunky. Being able to do the equivalent of "make && make check" is a really big deal. And "make check" needs to go fast. You keep ignore this point, perhaps because you don't care about this issue? Which is fine, and why we may just need to agree to disagree. Cheers, - Ted P.S. Running scripts is Turing-equivalent, so it's self-evident that *anything* you can do with other test frameworks you can somehow do in kselftests. That argument doesn't impress me, and why I do consider it quite flippant. (Heck, /bin/vi is Turing equivalent so we could use vi to as a kernel test framework. Or we could use emacs. Let's not. :-) The question is whether it is the most best and most efficient way to do that testing. And developer velocity is a really big part of my evaluation function when judging whether or a test framework is fit for that purpose.
