Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220310210210.2124637-1-brendanhiggins@google.com>
 <Yirz/hbo4K9zN9Ht@google.com> <CAFmMkTFa9xVt314WEGd0nNx+ovc=aGB_yN1LorP7WrBga9quxw@mail.gmail.com>
 <CAGS_qxqHhGEYS_4C-gTmPt_d3Fm==VOTEzQGggWh6MWppTHtZQ@mail.gmail.com> <CAFmMkTEoYXAFuz152SobMqnL3TM3GhQNDtR+_+RrzU=sx-bbRg@mail.gmail.com>
In-Reply-To: <CAFmMkTEoYXAFuz152SobMqnL3TM3GhQNDtR+_+RrzU=sx-bbRg@mail.gmail.com>
From:   Daniel Latypov <dlatypov@google.com>
Date:   Fri, 25 Mar 2022 10:59:31 -0500
Message-ID: <CAGS_qxqBuk1knE3424gV73wVgv5kJS5EGmd--bD2FAfuid5XGg@mail.gmail.com>
Subject: Re: [RFC v1] kunit: add support for kunit_suites that reference init code
To:     Daniel Gutson <daniel.gutson@eclypsium.com>
Cc:     David Gow <davidgow@google.com>,
        Brendan Higgins <brendanhiggins@google.com>, shuah@kernel.org,
        Martin Fernandez <martin.fernandez@eclypsium.com>,
        linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Richard Hughes <hughsient@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 25, 2022 at 8:26 AM Daniel Gutson
<daniel.gutson@eclypsium.com> wrote:
>
> On Fri, Mar 11, 2022 at 2:56 PM Daniel Latypov <dlatypov@google.com> wrot=
e:
> >
> > On Fri, Mar 11, 2022 at 4:14 AM Daniel Gutson
> > <daniel.gutson@eclypsium.com> wrote:
> > >
> > >
> > >
> > > El vie., 11 mar. 2022 4:02 a. m., David Gow <davidgow@google.com> esc=
ribi=C3=B3:
> > >>
> > >> On Thu, Mar 10, 2022 at 01:02:10PM -0800, Brendan Higgins wrote:
> > >> > Add support for a new kind of kunit_suite registration macro calle=
d
> > >> > kunit_test_init_suite(); this new registration macro allows the
> > >> > registration of kunit_suites that reference functions marked __ini=
t and
> > >> > data marked __initdata.
> > >> >
> > >> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > >> > ---
> > >> >
> > >> > This patch is in response to a KUnit user issue[1] in which the us=
er was
> > >> > attempting to test some init functions; although this is a functio=
nal
> > >> > 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 registra=
tion
> > >> > macro rather than simply modifying the existing macros.
> > >> >
> > >> > [1] https://groups.google.com/g/kunit-dev/c/XDjieRHEneg/m/D0rFCwVA=
BgAJ
> > >> >
> > >> > ---
> > >>
> > >> 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 informat=
ion
> > >> 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 somethin=
g...
> > >
> > >
> > > 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.

v1 of the patch was posted here:
https://lore.kernel.org/linux-kselftest/20220311072859.2174624-1-brendanhig=
gins@google.com/

It has the requisite Reviewed-by's and no one has complained about it.
So we're now waiting for that to get picked up into Shuah's tree and
into Linus' for 5.18 (possibly) or 5.19.