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