On Wed, Jul 26, 2023 at 10:54:41PM +0800, Zorro Lang wrote:
>
> Ahaha, I'm just waiting for Darrick wake up, then ask him is there any
> requirement/context about this patch. Due to he (looks like) a bit
> hurry to push this patch :)
>
> If most of you prefer this way (an ./check option, not a separated wrapper
> script), I'm OK with that.
I'm agnostic on that front, since I already *have* my own wrapper
script. So if we need to do it in the wrapper script, I'm certainly
OK with that. OTOH, if we think it's a feature which is generally
interesting to multiple developers and/or test wrappers, maybe it
makes sense to push things into the ./check sccript.
So I certainly don't have any objections to adding support to my
/root/runtests.sh so that "{gce,kvm,android}-xfstests smoke" gets ends
up running the moral equivalent of:
SOAK_DURATION=4m ./check -g smoketest
... and adding extra special case support in the check script just for
this use case. I'm doing enough other stuff in runtests.sh[1] that
it's really not a big deal for me. :-)
[1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/root/runtests.sh
More generally, there are some "intresting" hacks --- for example, I
want to be able to run code in between every single test run, and the
way I do it is a big ugly, but effective. I basically set
LOGGER_PROG to my own special script, gce-logger[2]
[2] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/lib/gce-logger
and this allows the user to upload a script which will get run in
between every single individual fstest (e.g., to grab information from
BPF, or grab and reset lockstats, etc.). This script also updates the
VM metadata so someone can query the VM to find out what test it's
currently running, and the percentage completion for that VM.
I could have asked for extra features in check, but whenever possible
I try to work around it to limit the number of special things just for
my set of wrapper scripts.
> Just recently I'm a bit worry about the ./check code, it's becoming more
> and more complex. I hope to separate something from it, but many things
> entwined, and growing. Anyway that's another story, I'll look into this
> patchset and review it soon.
Well, I don't use the config sections feature at all, because my
wrapper script has a lot more functionality than what you can get with
the config sections, so I just pass in TEST_DEV, SCRATCH_DEV,
MKFS_OPTIONS, etc., via environment variables, and I have my own set
of scripts to set up te test parameters.
So if you were going to simplify things by removing config sections,
*I* wouldn't care. Enough other people might be using it that
changing the fstests interface for this might raise a lot of
objections from other folks, though.
Cheers,
- Ted
