[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFmMkTEoYXAFuz152SobMqnL3TM3GhQNDtR+_+RrzU=sx-bbRg@mail.gmail.com>
Date: Fri, 25 Mar 2022 10:25:57 -0300
From: Daniel Gutson <daniel.gutson@...ypsium.com>
To: Daniel Latypov <dlatypov@...gle.com>
Cc: David Gow <davidgow@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>, shuah@...nel.org,
Martin Fernandez <martin.fernandez@...ypsium.com>,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
linux-kernel <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Richard Hughes <hughsient@...il.com>
Subject: Re: [RFC v1] kunit: add support for kunit_suites that reference init code
On Fri, Mar 11, 2022 at 2:56 PM Daniel Latypov <dlatypov@...gle.com> wrote:
>
> On Fri, Mar 11, 2022 at 4:14 AM Daniel Gutson
> <daniel.gutson@...ypsium.com> wrote:
> >
> >
> >
> > El vie., 11 mar. 2022 4:02 a. m., David Gow <davidgow@...gle.com> escribió:
> >>
> >> On Thu, Mar 10, 2022 at 01:02:10PM -0800, Brendan Higgins wrote:
> >> > Add support for a new kind of kunit_suite registration macro called
> >> > kunit_test_init_suite(); this new registration macro allows the
> >> > registration of kunit_suites that reference functions marked __init and
> >> > data marked __initdata.
> >> >
> >> > Signed-off-by: Brendan Higgins <brendanhiggins@...gle.com>
> >> > ---
> >> >
> >> > This patch is in response to a KUnit user issue[1] in which the user was
> >> > attempting to test some init functions; although this is a functional
> >> > solution as long as KUnit tests only run during the init phase, we will
> >> > need to do more work if we ever allow tests to run after the init phase
> >> > is over; it is for this reason that this patch adds a new registration
> >> > macro rather than simply modifying the existing macros.
> >> >
> >> > [1] https://groups.google.com/g/kunit-dev/c/XDjieRHEneg/m/D0rFCwVABgAJ
> >> >
> >> > ---
> >>
> >> I'm a little concerned that this is just removing the warnings, but do
> >> agree that this is safe enough for the moment. At least the information
> >> about which tests need __init is preserved by the use of a different
> >> macro.
> >>
> >> I guess one day we'll need a second list of 'init' tests or something...
> >
> >
> > Hi, could you please detail about this? Why a second list?
> >
>
> I assume this is referring to a future where we want to run tests
> _after_ the init phase.
> In that case, we'd need to be able to separately register tests that
> run during and those that run after.
> (Or we could have one list and just tag each suite as init/post-init.
> If we ever had >2 "phases" where we run tests, this might be the more
> scalable option)
>
> Is it likely we'd have tests run after?
> Not in the near future, I don't think. But it could be asked for.
>
> For context, here's where built-in KUnit tests currently run:
> https://elixir.bootlin.com/linux/v5.17-rc7/source/init/main.c#L1615
> That'd probably become kunit_run_init_tests() and then we'd have
> another kunit_run_post_init_tests() called later, or something.
Hi folks, any update on this? I'm adding Richard Hughes since we
need this for fwupd/LVFS, so he can provide more context.
Powered by blists - more mailing lists