On Tue, Sep 02, 2025 at 03:50:10PM +0100, John Garry wrote:
> On 22/08/2025 09:02, Ojaswin Mujoo wrote:
> > The main motivation of adding this function on top of _require_fio is
> > that there has been a case in fio where atomic= option was added but
> > later it was changed to noop since kernel didn't yet have support for
> > atomic writes. It was then again utilized to do atomic writes in a later
> > version, once kernel got the support. Due to this there is a point in
> > fio where _require_fio w/ atomic=1 will succeed even though it would
> > not be doing atomic writes.
> >
> > Hence, add an explicit helper to ensure tests to require specific
> > versions of fio to work past such issues.
> >
> > Signed-off-by: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx>
> > ---
> > common/rc | 32 ++++++++++++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/common/rc b/common/rc
> > index 35a1c835..f45b9a38 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -5997,6 +5997,38 @@ _max() {
> > echo $ret
> > }
> > +# Check the required fio version. Examples:
> > +# _require_fio_version 3.38 (matches 3.38 only)
> > +# _require_fio_version 3.38+ (matches 3.38 and above)
> > +# _require_fio_version 3.38- (matches 3.38 and below)
>
> This requires the user to know the version which corresponds to the feature.
> Is that how things are done for other such utilities and their versions vs
> features?
I don't like to use "version" to be the _require_ condition either. fstests always
recommend "checking if the feature/behavior is really supported" at first, not a
hard version limitation. Some old downstream software might backport new upstream
commits, the version is useless for them.
Thanks,
Zorro
>
> I was going to suggest exporting something like
> _require_fio_atomic_writes(), and _require_fio_atomic_writes() calls
> _require_fio_version() to check the version.
>
> Thanks,
> John
>
>
