Hi Mauro, Thanks for review. On Tuesday, 1 August 2023 15:17:11 CEST Mauro Carvalho Chehab wrote: > Em Mon, 31 Jul 2023 16:10:23 +0200 > Janusz Krzysztofik <janusz.krzysztofik@xxxxxxxxxxxxxxx> escreveu: > > > According to KTAP specification[1], results should always start from a > > header that provides a TAP protocol version, followed by a test plan with > > a count of items to be executed. That pattern should be followed at each > > nesting level. In the current implementation of the top-most, i.e., test > > suite level, those rules apply only for test suites built into the kernel, > > executed and reported on boot. Results submitted to dmesg from kunit test > > modules loaded later are missing those top-level headers. > > > > As a consequence, if a kunit test module provides more than one test suite > > then, without the top level test plan, external tools that are parsing > > dmesg for kunit test output are not able to tell how many test suites > > should be expected and whether to continue parsing after complete output > > from the first test suite is collected. > > > > Submit the top-level headers also from the kunit test module notifier > > initialization callback. > > > > [1] https://docs.kernel.org/dev-tools/ktap.html# > > > > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@xxxxxxxxxxxxxxx> > > --- > > lib/kunit/test.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/lib/kunit/test.c b/lib/kunit/test.c > > index 84e4666555c94..a29ca1acc4d81 100644 > > --- a/lib/kunit/test.c > > +++ b/lib/kunit/test.c > > @@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit); > > #ifdef CONFIG_MODULES > > static void kunit_module_init(struct module *mod) > > { > > + if (mod->num_kunit_suites > 0) { > > + pr_info("KTAP version 1\n"); > > + pr_info("1..%d\n", mod->num_kunit_suites); > > + } > > + > > __kunit_test_suites_init(mod->kunit_suites, mod->num_kunit_suites); > > } > > IMO, the best would be instead to export kunit_exec_run_tests() and > use it here too. I was considering a similar approach, i.e., moving those two pr_info() lines from built-in only kunit_exec_run_tests() to __kunit_test_suites_init() which is common to both built-in and modular paths, but please note that with kunit built in, an empty test plan "1..0" is now reported on boot, while we don't want similar reports to appear on loading modules that don't provide any kunit tests. Then, inside either your exported kunit_exec_run_tests() or my __kunit_test_suites_init(), we would have to check somehow if it has been called from a module notifier initialization callback, and that seemed to me too much complicated and less clean than what I've proposed: keep using unmodified kunit_exec_run_tests() in built-in and updated kunit_module_init() in modular processing path. Dropping the empty "1..0" test plan from boot messages would mean an ABI change, I believe, which I'd rather avoid adding to the scope of this patch as not required. Thanks, Janusz > > Except for the nit, LGTM. > > > Thanks, > Mauro >
