On Mon, Oct 11, 2021 at 9:38 PM David Gow <davidgow@xxxxxxxxxx> wrote: > > On Mon, Oct 11, 2021 at 10:10 AM Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx> 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
