Hi Brendan,
I think this change here should mostly go into lib/kunit/executor.c:
https://elixir.bootlin.com/linux/latest/source/lib/kunit/executor.c
Not totally sure how this should interact with printing the TAP header and some other functionality, but we already have some module params in there that we may want to pick up when KUnit is loaded as a module.
So I had a go at doing this as part of the executor, but that just raised more questions about how we want this to work for the various configurations of built-in/modules, where we have five options, assuming two example kunit consumers:
- CONFIG_example1_TEST=y - our built-in suite: suites end up in the vmlinux kunit_test_suites section
- CONFIG_example2_TEST=m - our modular suite: suites end up in the modules' kunit_test_suites section, to be iterated on module load.
Currently, it looks like we have:
CONFIG_KUNIT=y
1) example1's tests are run through the built-in init path: kernel_init_freeable() -> kunit_run_all_tests, which iterates through the built-in kunit_test_suites section
2) example2's tests are run through:
the module's own module_init(), -> __kunit_test_suites_init() - passing the suite to be init-ed and immediately run.
CONFIG_KUNIT=m - is where this gets tricky:
3) example1's tests are never run; we don't iterate the kunit_test_suites section when KUNIT=m (as kunit_run_all_tests() is empty)
4) loading example2.ko after kunit.ko will get example2's test run through example2's module_init -> __kunit_test_suites_init()
5) loading example2.ko before kunit.ko would result in an unresolved symbol, as __kunit_test_suites_init() doesn't exist yet.
Is that all correct?
With the proposed change to use a section for module's test suites:
(1) would stay as-is
(2) is similar, but the suites are loaded from the module's kuint_test_suites section rather than an explicit call from module_init().
(3) would stay as-is (but we could export the __kuint_test_suites section details, allowing kunit.ko to iterate the built-in suites - is this desirable?).
(4) is now the same as (2); once kunit.ko is present, it will be notified on subsequent module loads, and will extract tests from the module's own kuint_test_suites section
(5) does not result in any dependencies between example2.ko and kunit.ko. exmaple2.ko is able to be loaded before kunit.ko without symbol dep issues, but (of course) its tests will not be run. We have an option here to store the suites of loaded modules into a small built-in list, for kunit.ko to consume when it starts, similar to the changes possible in (3).
So - any preferences for the options there?
Cheers,
Jeremy