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

On Thu, Oct 17, 2019 at 5:51 AM Theodore Y. Ts'o <> wrote:
> On Wed, Oct 16, 2019 at 02:04:35PM -0700, Brendan Higgins wrote:
> > > > Should we maybe drop `--build_dir` in favor of `O`?
> > >
> > > Yes, preferably be consistent with the rest of the kernel makefiles.
> >
> > Alright, probably a good idea to make this change fairly soon then
> > before we have to worry about backwards compatibility and such.
> I'm not sure how this would work; so something like:
>     .../ run O=/build_dir

Seems reasonable to me.

> Should other flags we can pass in via the makefile processing, such as
> V=1, etc., also work?  What other things can we pass in via after the
> "run" command?

Hmmm...that's a good point. I don't know about V; probably need to
improve how kunit_tool displays build information for that to be
useful. I don't think that W is likely to be useful since I think that
is semantically a different operation than just running KUnit tests.

Probably don't want to forward ARCH, or CROSS_COMPILE or any of those.

Supporting some of these[1] seems useful.

> And if we're going to go this far, maybe we should make "make kunit"
> run tools/testing/kunit/

That seems reasonable. I was holding off on that initially because I
thought it might be a bridge too far in terms of putting KUnit in a
highly visible place. However, in hindsight, I think we crossed that
bridge a long time ago with putting tests is very visible places. So
yeah, now is probably a good time to do that.

> Some minor other nits if you're going to be making changes to
>'s CLI parsing:
> 1) It would be nice if there was a help command so that "
>    help" does what -h does.

Seems reasonable.

> 2) The top-level help message should indicate that " run"
>    takes various optional arguments and the way to find them is
>    " run -h".  This was *not* obvious, and the way I figured
>    out there was even --build_dir option was via purusing the source
>    code.  (It wasn't in the documentation that I could find.)

Also reasonable.

> 3) And maybe then " help run" should display the help message
>    for " urn".  This would make it consistent with other tools
>    that some of us might be familiar with (e.g., gcloud, gsutil, etc.)

That's reasonable, but also a little harder. At that point, I think we
might need to write our own flag library to support all this. So, I
will put this as a TODO, but we probably won't get to it for a while.

> Of course, if the front entry for kunit starts being "make kunit" as
> opposed to ./tools/testing/kunit/, then we really need to
> figure out how to pass in the equivalent of --timeout.  (Maybe

Yeah, that's true. We should probably also by default set --timeout to
a reasonable default instead of infinite.

> --raw_output is enabled if we run make kunit V=1?).  And of course,

Hmmm...that seems like a good idea.

> all of this would need to be documented.

Yeah, we very much need to improve our documentation, especially for
the kunit_tool. That is very high on our TODO list.


  reply	other threads:[~2019-10-18 22:12 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 [this message]
     [not found]   ` <>
2019-10-16 21:02     ` Brendan Higgins
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 \ \ \ \ \ \ \ \

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