From: Luis Chamberlain <mcgrof@kernel.org>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: linux-kselftest@vger.kernel.org, brendanhiggins@google.com,
skhan@linuxfoundation.org, keescook@chromium.org,
yzaikin@google.com, akpm@linux-foundation.org,
yamada.masahiro@socionext.com, catalin.marinas@arm.com,
joe.lawrence@redhat.com, penguin-kernel@i-love.sakura.ne.jp,
schowdary@nvidia.com, urezki@gmail.com,
andriy.shevchenko@linux.intel.com, changbin.du@intel.com,
kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 linux-kselftest-test 0/3] kunit: support building core/tests as modules
Date: Wed, 16 Oct 2019 12:47:15 +0000 [thread overview]
Message-ID: <20191016124715.GG16384@42.do-not-panic.com> (raw)
In-Reply-To: <alpine.LRH.2.20.1910141452470.6620@dhcp-10-175-191-179.vpn.oracle.com>
On Mon, Oct 14, 2019 at 03:02:03PM +0100, Alan Maguire wrote:
>
>
> On Mon, 14 Oct 2019, Luis Chamberlain wrote:
>
> > On Tue, Oct 08, 2019 at 03:55:43PM +0100, Alan Maguire wrote:
> > > The current kunit execution model is to provide base kunit functionality
> > > and tests built-in to the kernel. The aim of this series is to allow
> > > building kunit itself and tests as modules. This in turn allows a
> > > simple form of selective execution; load the module you wish to test.
> > > In doing so, kunit itself (if also built as a module) will be loaded as
> > > an implicit dependency.
> > >
> > > Because this requires a core API modification - if a module delivers
> > > multiple suites, they must be declared with the kunit_test_suites()
> > > macro - we're proposing this patch as a candidate to be applied to the
> > > test tree before too many kunit consumers appear. We attempt to deal
> > > with existing consumers in patch 1.
> >
> > This is neat and makes sense to me.
>
> Thanks for taking a look!
>
> > However the ordering of the patches
> > seems odd. If modules depend on kunit module, then shouldn't that go
> > first? Ie, we want this to be bisectable in proper order.
> >
>
> The reasoning here is it seemed a more likely scenario that users mught
> build kunit built-in (CONFIG_KUNIT=y) along with test suites built as
> modules (CONFIG_KUNIT_TEST=m). So the intermediate state after patch 2 -
> tests buildable as modules while kunit is still built-in-only - made more
> sense to me as something users might do in practice so that's why I
> ordered things that way. I'm working on a new revision of the patchset
> though, so if you feel strongly about this shout and I'll try and accommodate
> the alternative ordering.
No, that makes sense. All good.
Luis
prev parent reply other threads:[~2019-10-16 12:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 14:55 [PATCH v2 linux-kselftest-test 0/3] kunit: support building core/tests as modules Alan Maguire
2019-10-08 14:55 ` [PATCH v2 linux-kselftest-test 1/3] kunit: allow kunit tests to be loaded as a module Alan Maguire
2019-10-08 21:35 ` Brendan Higgins
2019-10-09 16:35 ` Alan Maguire
2019-10-11 9:47 ` Brendan Higgins
2019-10-11 10:25 ` Alan Maguire
2019-10-16 23:01 ` Brendan Higgins
2019-10-17 18:32 ` Alan Maguire
2019-10-18 12:21 ` Luis Chamberlain
2019-10-24 1:33 ` Brendan Higgins
2019-10-08 14:55 ` [PATCH v2 linux-kselftest-test 2/3] kunit: allow kunit " Alan Maguire
2019-10-08 15:13 ` Randy Dunlap
2019-10-08 14:55 ` [PATCH v2 linux-kselftest-test 3/3] kunit: update documentation to describe module-based build Alan Maguire
2019-10-08 21:47 ` Brendan Higgins
2019-10-08 21:00 ` [PATCH v2 linux-kselftest-test 0/3] kunit: support building core/tests as modules Brendan Higgins
2019-10-14 9:20 ` Luis Chamberlain
2019-10-14 14:02 ` Alan Maguire
2019-10-16 12:47 ` Luis Chamberlain [this message]
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=20191016124715.GG16384@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alan.maguire@oracle.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brendanhiggins@google.com \
--cc=catalin.marinas@arm.com \
--cc=changbin.du@intel.com \
--cc=joe.lawrence@redhat.com \
--cc=keescook@chromium.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=schowdary@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=urezki@gmail.com \
--cc=yamada.masahiro@socionext.com \
--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).