From: Alan Maguire <alan.maguire@oracle.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Alan Maguire <alan.maguire@oracle.com>,
Iurii Zaikin <yzaikin@google.com>,
David Gow <davidgow@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
rppt@linux.ibm.com, Greg KH <gregkh@linuxfoundation.org>,
Stephen Boyd <sboyd@kernel.org>,
Logan Gunthorpe <logang@deltatee.com>,
Knut Omang <knut.omang@oracle.com>,
linux-um <linux-um@lists.infradead.org>,
linux-arch@vger.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v1 0/6] kunit: create a centralized executor to dispatch all KUnit tests
Date: Wed, 29 Jan 2020 13:06:34 +0000 (GMT) [thread overview]
Message-ID: <alpine.LRH.2.20.2001291006570.13921@dhcp-10-175-173-43.vpn.oracle.com> (raw)
In-Reply-To: <e801e4ac-b7c2-3d0a-71e7-f8153a3dfbc8@gmail.com>
On Tue, 28 Jan 2020, Frank Rowand wrote:
> On 1/28/20 1:19 AM, Brendan Higgins wrote:
> > On Mon, Jan 27, 2020 at 9:40 AM Frank Rowand <frowand.list@gmail.com> wrote:
> >>
> >> On 1/23/20 4:40 PM, Brendan Higgins wrote:
> >>> Sorry for the late reply. I am still catching up from being on vacation.
> >>>>> On Mon, Jan 6, 2020 at 2:40 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >>>> It does beg the question if this means kunit is happy to not be a tool
> >>>> to test pre basic setup stuff (terminology used in init.c, meaning prior
> >>>> to running all init levels). I suspect this is the case.
> >>>
> >>> Not sure. I still haven't seen any cases where this is necessary, so I
> >>> am not super worried about it. Regardless, I don't think this patchset
> >>> really changes anything in that regard, we are moving from late_init
> >>> to after late_init, so it isn't that big of a change for most use
> >>> cases.
> >>>
> >>> Please share if you can think of some things that need to be tested in
> >>> early init.
> >>
> >> I don't have a specific need for this right now. I had not thought about
> >> how the current kunit implementation forces all kunit tests to run at a
> >> specific initcall level before reading this email thread.
> >>
> >> I can see the value of being able to have some tests run at different
> >> initcall levels to verify what functionality is available and working
> >> at different points in the boot sequence.
> >
> > Let's cross that bridge when we get there. It should be fairly easy to
> > add that functionality.
>
> Yes. I just wanted to add the thought to the back of your mind so that
> it does not get precluded by future changes to the kunit architecture.
>
> >
> >> But more important than early initcall levels, I do not want the
> >> framework to prevent using or testing code and data that are marked
> >> as '__init'. So it is important to retain a way to invoke the tests
> >> while __init code and data are available, if there is also a change
> >> to generally invoke the tests later.
> >
> > Definitely. For now that still works as long as you don't build KUnit
> > as a module, but I think Alan's new patches which allow KUnit to be
> > run at runtime via debugfs could cause some difficulty there. Again,
>
> Yes, Alan's patches are part of what triggered me thinking about the
> issues I raised.
>
>
As Brendan says, any such tests probably shouldn't be buildable
as modules, but I wonder if we need to add some sort of way
to ensure execution from debugfs is not allowed for such cases?
Even if a test suite is builtin, it can be executed via debugfs
in the patches I sent out, allowing suites to be re-run. Sounds
like we need a way to control that behaviour based on the
desired test suite execution environment.
Say, for example, the "struct kunit_suite" definitions associated
with the tests was marked as __initdata; are there any handy macros to
identify it as being in the __init section? If so, we could simply
avoid adding a "run" file to the debugfs representation for such
suites. Failing that, perhaps we need some sort of flags field
in "struct kunit_suite" to specify execution environment constraints?
Thanks!
Alan
next prev parent reply other threads:[~2020-01-29 13:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 22:05 [RFC v1 0/6] kunit: create a centralized executor to dispatch all KUnit tests Brendan Higgins
2019-12-16 22:05 ` [RFC v1 1/6] vmlinux.lds.h: add linker section for KUnit test suites Brendan Higgins
2019-12-17 8:21 ` Stephen Boyd
2019-12-16 22:05 ` [RFC v1 2/6] arch: um: " Brendan Higgins
2019-12-17 8:21 ` Stephen Boyd
2019-12-16 22:05 ` [RFC v1 3/6] kunit: test: create a single centralized executor for all tests Brendan Higgins
2019-12-17 8:04 ` Stephen Boyd
2020-01-23 22:54 ` Brendan Higgins
2019-12-16 22:05 ` [RFC v1 4/6] init: main: add KUnit to kernel init Brendan Higgins
2019-12-17 7:58 ` Stephen Boyd
2020-01-23 22:45 ` Brendan Higgins
2019-12-16 22:05 ` [RFC v1 5/6] kunit: test: add test plan to KUnit TAP format Brendan Higgins
2019-12-17 8:18 ` Stephen Boyd
2019-12-16 22:05 ` [RFC v1 6/6] kunit: Add 'kunit_shutdown' option Brendan Higgins
2019-12-17 8:06 ` Stephen Boyd
2020-01-23 22:56 ` Brendan Higgins
2020-01-06 22:40 ` [RFC v1 0/6] kunit: create a centralized executor to dispatch all KUnit tests Luis Chamberlain
2020-01-23 22:40 ` Brendan Higgins
2020-01-27 17:40 ` Frank Rowand
2020-01-28 7:19 ` Brendan Higgins
2020-01-28 18:36 ` Frank Rowand
2020-01-28 19:35 ` Tim.Bird
2020-01-28 19:53 ` Brendan Higgins
2020-01-29 4:24 ` Frank Rowand
2020-01-29 21:18 ` Brendan Higgins
2020-01-29 13:06 ` Alan Maguire [this message]
2020-01-29 21:28 ` Brendan Higgins
2020-03-02 19:45 ` Luis Chamberlain
2020-03-02 19:05 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.20.2001291006570.13921@dhcp-10-175-173-43.vpn.oracle.com \
--to=alan.maguire@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=arnd@arndb.de \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jdike@addtoit.com \
--cc=keescook@chromium.org \
--cc=knut.omang@oracle.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=logang@deltatee.com \
--cc=mcgrof@kernel.org \
--cc=richard@nod.at \
--cc=rppt@linux.ibm.com \
--cc=sboyd@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).