On Mon, Oct 11, 2021 at 9:38 PM David Gow davidgow@google.com wrote:
On Mon, Oct 11, 2021 at 10:10 AM Jeremy Kerr jk@codeconstruct.com.au wrote:
Hey Jeremy, small world! :-)
Hi David,
In any case, thanks a lot -- this is awesome.
Oh neat, glad it's useful!
I'm happy to keep hacking on this if it's in a direction that makes sense for kunit in general. As an approximate plan, I can fix the UML breakages, then work on some resulting simplifications for tree-wide initialisers (we'd no longer need the null-terminated arrays of suites everywhere, for example).
+dlatypov, +kunit-dev
Yeah, we think this would be a much better direction for KUnit to go for modules. If you're happy to work on it, that'd be great! Brendan, Daniel (CCed), and I would be more than willing to help out with questions, reviews, etc, as well.
+1 to David. My immediate reaction to looking at your diff is that it is the way that module support *should have* always worked, (No offense to those who worked on KUnit module support in the past: any module support was a big improvement over none.) your implementation is so much simpler and less obtrusive.
On the other hand, if you're really busy and you'd rather we pick this up, improved module support has been on the to-do list for ages, so we could bump it up the list a bit and finish it off.
The UML breakages were mostly pretty simple: our default config doesn't require module support at all, so the various functions should just need to go behind the appropriate #ifdefs. A quick way to test it is just to run './tools/testing/kunit/kunit.py run' from the kernel source directory, which will configure, build, and run everything in the .kunit builddir.
Cheers