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. 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. Luis
