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