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
