On Fri, Jan 28, 2022 at 4:19 PM Daniel Latypov firstname.lastname@example.org wrote:
On Wed, Oct 13, 2021 at 6:55 PM Jeremy Kerr email@example.com wrote:
Resulting in the .kunit_test_suites section just being a set of contiguous pointers to struct kunit_suite. We get the number of suites from the section size.
That was my thinking, anyway. I think it probably makes sense to do that cleanup after the section patch, as that means we don't need any post-processing on the suites arrays.
To be honest, I'm actually tempted to pay the cost of postprocessing and proposing a change like this for real. Going from kunit_suite*** to ** shaves off a lot of code from the unit test and the filtering code path.
Specifically I'm thinking this can go into the kunit branch, https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/?h... Then when we have the series reworking modules, one of two things can happen.
- if we get to kunit_suite** with null-terminated arrays, fixing the
executor just means dropping the post-processing step. 2. If we get to kunit_suite* as mentioned above, then there'll be a bit more work, but not as much.
Alternatively, I can wait and send you an updated version of this patch to include at the start of your series like PATCH 1/x: this patch with post-processing, using either * or ** ... PATCH x/x: final rework, and drop the postprocessing
It's just that the prospect of submitting a patch that reduces so much code makes me eager to try and get it submitted :)
I agree. Honestly, just changing the type signature from `struct kunit_suite * const * const *` to `struct kunit_suite * const *` in the suite_set struct sells me on this. I missed this before, but now that I am aware of this, I would like to see it go in soon.
Brendan and David seem ok with paying the bit of runtime overhead for post-processing, esp. if we time it so this patch lands in the same
I'm absolutely fine with it. We are nowhere near the point where that matters at all.
Linux release as the module rework. But I can hold off if it'll make your life more difficult.
Also agree. I am excited to see Jeremy's new module code. I don't want to make his life any harder than it already is ;-)