Re: [PATCH] kunit: Add "hooks" to call into KUnit when it's built as a module

[David Gow]

On Tue, 31 Jan 2023 at 08:04, Brendan Higgins <brendanhiggins@xxxxxxxxxx> wrote:
>
> On Sat, Jan 28, 2023 at 2:10 AM 'David Gow' via KUnit Development
> <kunit-dev@xxxxxxxxxxxxxxxx> wrote:
> >
> > KUnit has several macros and functions intended for use from non-test
> > code. These hooks, currently the kunit_get_current_test() and
> > kunit_fail_current_test() macros, didn't work when CONFIG_KUNIT=m.
> >
> > In order to support this case, the required functions and static data
> > need to be available unconditionally, even when KUnit itself is not
> > built-in. The new 'hooks.c' file is therefore always included, and has
> > both the static key required for kunit_get_current_test(), and a table
> > of function pointers in struct kunit_hooks_table. This is filled in with
> > the real implementations by kunit_install_hooks(), which is kept in
> > hooks-impl.h and called when the kunit module is loaded.
> >
> > This can  be extended for future features which require similar
> > "hook" behaviour, such as static stubs, by simply adding new entries to
> > the struct, and the appropriate code to set them.
> > Signed-off-by: David Gow <davidgow@xxxxxxxxxx>
>
> I agree with Rae that a new file for just setting the pointer seems a
> bit much, but I also understand the point of separating it out now -
> not sure of a better place for it to live. Aside from that, looks good
> to me:
>
> Reviewed-by: Brendan Higgins <brendanhiggins@xxxxxxxxxx>

Thanks Rae and Brendan.

The reasoning behind the separate file here is that, because the hook
implementations are not "static" (as they can be found spread across
different files), they need to have a separate prototype. This
would've required two prototypes (one in the file which had the
implementation, one in the file which set the pointer), so it made
sense to combine these into one header.

Adding the code to set the function pointers to that header made sense
just to keep a couple of the lists of hooks together. It's still a
pain that these are spread between "hooks-impl.h" and "test-bug.h",
but it's probably worth it to avoid either making all of the hook
implementations even more public, or using the more complicated macro
magic (at least for now).

Cheers,
-- David

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