On Wed, Jul 26, 2023 at 04:59:30PM -0400, Theodore Ts'o wrote:
> 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
Hi Ted,
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.
Thanks,
Zorro
>
> ... 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
>
