linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brendan Higgins <brendanhiggins@google.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	"Theodore Ts'o" <theodore.tso@gmail.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	KUnit Development <kunit-dev@googlegroups.com>
Subject: Re: kunit.py should default to --build_dir=.kunit
Date: Fri, 18 Oct 2019 15:12:08 -0700	[thread overview]
Message-ID: <CAFd5g45S57PsghpOiL2+6qcEjUdMG1XSzU97fUqCvEV7XvOGQA@mail.gmail.com> (raw)
In-Reply-To: <20191017125154.GD25548@mit.edu>

On Thu, Oct 17, 2019 at 5:51 AM Theodore Y. Ts'o <tytso@mit.edu> 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:
>
>     .../kunit.py 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/kunit.py?

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
> kunit.py's CLI parsing:
>
> 1) It would be nice if there was a help command so that "kunit.py
>    help" does what kunit.py -h does.

Seems reasonable.

> 2) The top-level help message should indicate that "kunit.py run"
>    takes various optional arguments and the way to find them is
>    "kunit.py 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 "kunit.py help run" should display the help message
>    for "kunit.py 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/kunit.py, 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.

[1] https://www.gnu.org/software/make/manual/html_node/Options-Summary.html

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c99604e5-2ea4-4075-9a39-470104298368@googlegroups.com>
2019-10-11 11:19 ` kunit.py 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]   ` <551223d0-7712-41df-90f2-3ca3da301435@googlegroups.com>
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:
  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=CAFd5g45S57PsghpOiL2+6qcEjUdMG1XSzU97fUqCvEV7XvOGQA@mail.gmail.com \
    --to=brendanhiggins@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=theodore.tso@gmail.com \
    --cc=tytso@mit.edu \
    /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).