Re: kunit.py should default to --build_dir=.kunit

["Theodore Y. Ts'o" <tytso@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

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?

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

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

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
--raw_output is enabled if we run make kunit V=1?).  And of course,
all of this would need to be documented.

					- Ted