On Mon, Oct 14, 2019 at 03:02:03PM +0100, Alan Maguire wrote:
On Mon, 14 Oct 2019, Luis Chamberlain wrote:
On Tue, Oct 08, 2019 at 03:55:43PM +0100, Alan Maguire wrote:
The current kunit execution model is to provide base kunit functionality and tests built-in to the kernel. The aim of this series is to allow building kunit itself and tests as modules. This in turn allows a simple form of selective execution; load the module you wish to test. In doing so, kunit itself (if also built as a module) will be loaded as an implicit dependency.
Because this requires a core API modification - if a module delivers multiple suites, they must be declared with the kunit_test_suites() macro - we're proposing this patch as a candidate to be applied to the test tree before too many kunit consumers appear. We attempt to deal with existing consumers in patch 1.
This is neat and makes sense to me.
Thanks for taking a look!
However the ordering of the patches seems odd. If modules depend on kunit module, then shouldn't that go first? Ie, we want this to be bisectable in proper order.
The reasoning here is it seemed a more likely scenario that users mught build kunit built-in (CONFIG_KUNIT=y) along with test suites built as modules (CONFIG_KUNIT_TEST=m). So the intermediate state after patch 2 - tests buildable as modules while kunit is still built-in-only - made more sense to me as something users might do in practice so that's why I ordered things that way. I'm working on a new revision of the patchset though, so if you feel strongly about this shout and I'll try and accommodate the alternative ordering.
No, that makes sense. All good.
Luis