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

Sorry for the delayed reply. I was on vacation.

On Fri, Oct 11, 2019 at 5:16 AM Theodore Ts'o <> wrote:
> On Friday, October 11, 2019 at 7:19:49 AM UTC-4, Brendan Higgins wrote:
>> Should we maybe drop `--build_dir` in favor of `O`?
> How about if "make kunit" results in "./tools/testing/kunit/ run --build_dir=/.kunit --allconfig"
> ... where --allconfig automatically creates kunitconfig but in includes all of the CONFIG options which depends on CONFIG_KUNIT, so that all unit tests are run?    That way, we make it super easy for people to run the unit tests.  Since most users are used using make targets, this I bet will significantly increase the number of developers using kunit, because it will be super-duper convenient for them.
> Also, it would be nice if first looks for kunitconfig in build_dir, and then in the top-level of the kernel sources, and we put .kunit in .gitignore.   That will make "git status" look nice and clean.
> What do folks think?

Having something like --allconfig is the ultimate goal. I had been
talking to Luis and Shuah about this for some time.

I think the best way to make this work would be for kunit_tool to be
able to detect all the tests with CONFIG_KUNIT as you suggest (or
something like it). Luis actually already suggested it; however, we
identified that this would likely not be as easy as it sounds as it is
possible to have mutually exclusive CONFIGs. Luis pointed out that
some researchers are currently working on a sat solver for Kconfig
that we could use to potentially address this problem. Nevertheless, a
complete solution in this regard is actually somewhat difficult.

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?

  parent reply	other threads:[~2019-10-16 21:03 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 [this message]
2019-10-18 12:43       ` Luis Chamberlain
2019-10-18 22:22         ` Brendan Higgins

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