archive mirror
 help / color / mirror / Atom feed
From: Brendan Higgins <>
To: Luis Chamberlain <>
Cc: "Theodore Ts'o" <>,
	shuah <>,
	KUnit Development <>,
	David Gow <>
Subject: Re: should default to --build_dir=.kunit
Date: Fri, 18 Oct 2019 15:22:59 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Oct 18, 2019 at 5:43 AM Luis Chamberlain <> wrote:
> On Wed, Oct 16, 2019 at 02:02:52PM -0700, Brendan Higgins wrote:
> > Shuah's solution was just to use CONFIG fragments in the meantime
> > similar to what kselftest already does. I was leaning in that
> > direction since kselftest already does that and we know that it works.
> >
> > Shuah, Luis, does this still match what you have been thinking?
> I personally never use the selftest full config thing myself, however I
> do use subcomponent selftests configs as hints to edit my .config to add
> what I need and then run 'make menuconfig', in hopes that that leaves a
> .config with all that is needed.
> So indeed, I believe ethis works well for now, and it works for me.

Okay, good to know. So that is probably the right thing to do until we
can come up with a good solution to the dynamically generating an
allconfig problem.

> I've hinted elsewhere that there is a difference between what kernel
> features you have enabled Vs what components are needed / should we
> built to test the current target kernel .config. And even then, what we
> test in userspace is in my view different than what should be configured
> in the kernel. To scale this I think a respective .config for userspace


> and respective symbols for testing may be in order, this way the
> userspace tests can only be visible say if you enabled certain features
> in your kernel.  How this gets exposed, etc, is a separate question,

I think that is a reasonable idea, but I don't think that really
applies here. I don't think it really makes sense to have the `make
kunit` that Ted is describing here do anything involving userspace.
That should just run the KUnit tests in the kernel. In anycase, I
expressed my ideas on the matter in more detail on the hybrid testing

> however I think this can be addressed later, and I believe Knut will
> likely be dealing with it during the KTF merge to kunit work as
> currently it addresses this via generic netlink, and we want something
> simple to start off with.



      reply	other threads:[~2019-10-18 22:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-10-11 11:19 ` should default to --build_dir=.kunit Brendan Higgins
2019-10-11 14:56   ` Randy Dunlap
2019-10-16 21:04     ` Brendan Higgins
2019-10-17 12:51       ` Theodore Y. Ts'o
2019-10-18 22:12         ` Brendan Higgins
     [not found]   ` <>
2019-10-16 21:02     ` Brendan Higgins
2019-10-18 12:43       ` Luis Chamberlain
2019-10-18 22:22         ` Brendan Higgins [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \

* 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).