On Tue, 28 Mar 2023 at 18:35, Johannes Berg johannes@sipsolutions.net wrote:
Hi all,
Is there an established process for new kunit infrastructure?
Hi Johannes,
"established process" is probably overselling it, but we're more than happy to accept improvements and additions to KUnit.
For example, we have this macro that makes KUNIT_ARRAY_PARAM easier by letting you just declare an array of test cases:
/* Similar to KUNIT_ARRAY_PARAM, but avoiding an extra function */ #define KUNIT_ARRAY_PARAM_DESC(name, array, desc_member) \ static const void *name##_gen_params(const void *prev, char *desc) \ { \ typeof((array)[0]) *__next = prev ? ((typeof(__next)) prev) + 1 : (array); \ if (__next - (array) < ARRAY_SIZE((array))) { \ strscpy(desc, __next->desc_member, KUNIT_PARAM_DESC_SIZE); \ return __next; \ } \ return NULL; \ }
Very neat! I'm more than happy to see this added.
Also, since we're working on wifi and thus networking, we want e.g. SKBs to be resource-managed, and added some helper macros/functions for using kunit_alloc_resource() with SKBs, that will be used at least in cfg80211 and mac80211 soon, so it would seem appropriate to have include/kunit/skb.h (and a corresponding C file somewhere) with these helpers.
We're definitely in favour of adding these sorts of helpers. Thus far, these have mostly lived alongside the tests or subsystem being tested, but if they're widely useful then they can sit alongside the KUnit code.
My personal feeling is that it's better to have these sorts of subsystem-specific helpers be written and maintained as part of the subsystems (like the tests themselves), largely because that's where the subsystem expertise lies, but we're definitely happy to review any such patches to make sure they fit into the KUnit infrastructure well. (And, of course, if something spans several subsystems, then lib/kunit may be the best place to keep it.)
Is all of this just a case of "nobody needed it so far", or is there no expectation to add such infrastructure more generally?
Yeah, it's a combination of "no-one has needed it yet", "no-one working on KUnit understands it well enough", and "we haven't had the time yet". We are a bit hesitant to add these features without having tests that use them, too: often things will be coded by hand for one or two tests, and only then refactored out into a common helper.
There are a few other similar helpers being worked on at the moment, mostly around providing test-managed "struct device"s, so this is definitely an active field of development.
Thanks, -- David