Re: new kunit infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 28 Mar 2023 at 18:35, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux