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:
- It would be nice if there was a help command so that "kunit.py help" does what kunit.py -h does.
Seems reasonable.
- 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.
- 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