Re: [PATCH v5 linux-kselftest-test 3/6] kunit: allow kunit tests to be loaded as a module

[Alan Maguire]

On Wed, 4 Dec 2019, Iurii Zaikin wrote:

> > I've also got a patch that I was hoping to send out soon
> > that might help.  The idea is that each test suite would create
> > a debugfs representation under /sys/kernel/debug/kunit;
> > specifically:
> >
> > /sys/kernel/debug/kunit/results/<suite>
> > /sys/kernel/debug/kunit/results/<suite>-tests
> >
> > ...where cat'ing the former shows the full set of results,
> > and the latter is a directory within which we can display
> > individual test results in test-case-specific files.
> >
> > This is all done by ensuring that when tests log information,
> > they log to a per-test-case log buffer as well as to dmesg.
> >
> > If the above sounds useful, I'll try and polish up the patch
> > for submission. Thanks!
> What would be the best way for kunit_tool to:
> 1. Know that the tests have completed as QEMU will be just sitting
> there with kernel complaining about the absence of init (or running
> whatever we give it as init)?
> 2. Read the test results from debugfs under QEMU virtual machine while
> the kernel is still there?
> I think supplying an init script/binary that copies the
> /sys/kernel/debug/kunit/results/* to a 9p shared dir set up by
> kunit_tool would work but it would add a step of cross-compiling and
> packaging a userspace binary.
> 

I confess I'd only been thinking about supporting the case of a user 
modprobe-ing a kunit test suite module directly and wanting a clean set 
of results separated from other dmesg output. However the scheme you 
describe does seem workable for the UML case also.  With the 
late_initcalls the builtin kunit suites will likely run early in boot but perhaps we could tweak the 
semantics such that the full results debugfs file is not populated until 
the tests have run to simplify script-based probing. I'll try some 
experiments with the debugfs patch once it's ready. Thanks!

Alan