[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