On Fri, Oct 11, 2019 at 2:05 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> <looks at kunit>
>
> Given that everything runs at late_initcall time, shouldn't everything
> be __init, __initdata etc so all the code and data doesn't hang around
> for ever?
>

That's an interesting point. We haven't done this for KUnit tests to
date, and there is certainly a possibility down the line that we may
want to be able to run these tests in other circumstances. (There's
some work being done to allow KUnit and KUnit tests to be built as
modules here: https://lkml.org/lkml/2019/10/8/628 for example.) Maybe
it'd be worth having macros which wrap __init/__initdata etc as a way
of futureproofing tests against such a change?

Either way, I suspect this is something that should probably be
considered for KUnit as a whole, rather than on a test-by-test basis.

On Fri, Oct 11, 2019 at 2:06 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 10 Oct 2019 11:56:31 -0700 David Gow <davidgow@google.com> wrote:
>
> > Reply-To: 20191007213633.92565-1-davidgow@google.com
>
> That's a bit irksome.  Deliberate?

Whoops, this was supposed to be In-Reply-To. Please ignore it.


On Fri, Oct 11, 2019 at 2:07 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 10 Oct 2019 11:56:31 -0700 David Gow <davidgow@google.com> wrote:
> >  lib/list-test.c   | 738 ++++++++++++++++++++++++++++++++++++++++++++++
>
> Should this be lib/kunit/list-test.c?
>

The idea here was to have KUnit tests co-located with the code being
tested, but with the linked-list code contained to a header, lib/
seemed the best place to put it, being alongside list_debug.c and
similar.
lib/kunit just contains the implementation for the KUnit framework
itself (and tests which test that framework).

Cheers,
-- David