On 3/28/17 12:35 PM, Amir Goldstein wrote: > On Tue, Mar 28, 2017 at 12:42 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >> I am (literally) in the woods this week so can't really comment at length, but generally: >> >> xfs_io is useful to facilitate testing at times, but usually doesn't have tests built into the tool itself. >> > > David, > > Eric being the maintainer, so he gets to decide, but he is being > somewhat subtle. Sorry about that. More like: terse, with only a phone to communicate, and a wife who thinks we're on vacation. ;) > There is no precedence AFAIK to tests within xfs_io. > Instead of comparing to stat with -c flag, you can make sure that > output of xfs_io -c 'statx -c' > is fully compatible to output of xfs_io -c 'stat -v' and do the test in scripts. *nod* >> And I think you are right that it is a poor fit for some of the testing you'd like to do. >> There is a src/ dir in xfstests for specialized C tests which get called by the test harness; that might also be a reasonable option. >> > > That's actually the shortest path for you and there are quite a few > tests in xfstests that took > this path. It should be easy for you to copy & paste one of them. > > That's not instead of adding xfs_io statx - just for tests that are > not natural to do with xfs_io. Agreed. I think there's value in having a statx command in xfs_io, but it won't be able to facilitate testing /everything/ that needs to be tested. Thanks, -Eric >> Thanks, >> Eric >> >>> On Mar 28, 2017, at 9:41 AM, David Howells <dhowells@xxxxxxxxxx> wrote: >>> >>> Note that the intention is to put the testing of the syscall parameter >>> handling into LTP, along with testing of the symlink following and dirfd usage >>> since xfstests seems unsuitable for this. >>> >>> David >> > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
