Re: [PATCH 1/2] check: add a -smoketest option

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Jul 27, 2023 at 11:25:37AM +0800, Zorro Lang wrote:
> > SOAK_DURATION=4m ./check -g smoketest
> 
> Now we provide two ways to help to customize testing in fstests:
> 
> 1)
> https://lore.kernel.org/fstests/20230727030529.r4ivp6dmtrht5zo2@zlang-mailbox/T/#mc5cdb59344f4cd681515bf0fab501d7f30f1e263
> 
> 2)
> https://lore.kernel.org/fstests/169033660570.3222210.3010411210438664310.stgit@frogsfrogsfrogs/T/#u
> 
> Which one do you like to use? I'd like to hear more review points before I
> choose one to merge.

(1) is the "./check -t smoketest" option, and it provides a more
generic way of adding new templates.  On the positive side it allows
more of this kind of simple "configuration" style options where "-t
smoketest" is essentially syntactic sugar for:

	SOAK_DURATION=${SOAK_DURATION:-4m} ./check -g smoketest"

The potential disadvantage of (1) is that it seems like extra
complexity for what is really simple.


(2) is "./check -smoketest" option.  Its advantage is that it might
easier for a drive-by patcher to type.  The disadvantage is that it's
adding Yet Another Option to the ./check script.

I also will note that we have some "long options" which use a single
hypen (e.g., -overlay and -udiff) but newer "long options" seem to use
the double hypehn approach (e.g., --exact-order and --large-fs).  My
personal preference is for the newer GNU getopt style of using double
hyphens, but the fact that we have both types of long options
is... unfortunate.


I guess I have a slight preference for (1), but I'm really not sure
either is really necessary.  My view is that for a drive-by tester,
trying to set up xfstests is Too Hard.  So the reality is they will be
using some kind of wrapper script --- either one that they've written
for their own, such as what Darrick (and I assume other XFS developers
have their own), or they're using something like kdevops or
kvm-xfstests.

From *my* perspective, I have absolutely *no* problem with having my
wrapper script use:

	SOACK_DURATION=4m ./check -g smoketest

because I only have to do it once, and no end-user is ever going to
see it.  They will just use "kvm-xfstests smoke", and all of the magic
will be hidden from them.

The main advantage of having some kind of "official" top-level way of
specifying the smoke test is that it makes it more likely that
different wrapper scripts will converge on the same kind of smoke
test, and it becomes easier for fstests developers to communicate with
each other because the concept of what a "smoke test" is has been well
defined in the fstests source code.  And for that purpose, I think the
"./check -t smoketest" approach works just fine.

But really, I can live with either.   :-)

Cheers,

						- Ted