[LTP] [PATCH] statx04: Re-add BTRFS version check
Cyril Hrubis
chrubis@suse.cz
Mon Nov 22 14:30:30 CET 2021
Hi!
> Do you mean that your distribution based on older kernel ie 4.11
> supports statx syscall but btrfs missed the btrfs patch? Also this
> distribution doesn't update and so have no choice to backport.
> > This is different from the
> > other version checks which are for much newer kernels.
> IMO, distribution based on older kernel 4.11 still can make ext2 ext4
> xfs supports statx because the backport looks not diffcult. So, I don't
> think this is a difference. It depends on kernel users worked on this
> distirbution whether have this requirement.
> Also there could be differences in the difficulty of a backport.
> I see xfs/btrfs code, it only fills the attributes field of stat
> struture by parsing inode flags.
>
> If you must add this check on suse distribution, I guess you just add
> this version check for suse distribution. For centos7,8, neither of them
> supports btrfs, but I don't know other distribution situation ie unbuntu.
I just checked debian, both oldstable (4.16) and stable (5.10) have new
enough kernels for this not to matter.
> Maybe you can just add suse detection in lib/tst_kvercmp.c.
I guess that this would be the cleanest solution.
Actually SUSE should be detected just fine, since we parse
/etc/os-release for ID='foo' in the test library.
So this could be solved just by defining:
static struct tst_kern_exv kvers[] = {
{"sles", "4.13.0"}
{}
};
and then doing:
if (tst_kvercmp2(0, 0, 0, kvers) < 0)
tst_brk(TCONF, "Btrfs statx() supported since 4.13");
Also it would be a bit cleaner to add this to the tst_test structure as
.min_kver_ex as well, but that's a different story...
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list