On 9/9/16 3:47 AM, Xiao Yang wrote: > Signed-off-by: Xiao Yang <yangx.jy@xxxxxxxxxxxxxx> > --- > tests/xfs/263 | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/tests/xfs/263 b/tests/xfs/263 > index 1dc47ae..07f7ebc 100755 > --- a/tests/xfs/263 > +++ b/tests/xfs/263 > @@ -58,6 +58,10 @@ _require_xfs_quota > _require_xfs_mkfs_crc > _require_xfs_crc > > +# check if Q_XGETQSTATV has been supported by kernel and xfsprogs > +grep -q 'Q_XGETQSTATV' /usr/include/linux/dqblk_xfs.h || _notrun "Q_XGETQSTATV hasn't been supported by kernel" > +grep -q 'Q_XGETQSTATV' /usr/include/xfs/xqm.h || _notrun "Q_XGETQSTATV hasn't been supported by xfsprogs" The installed headers may not even exist; if they are, they won't tell us anything about the binaries we're running. If you really want to test for its presence, you'd need to somehow directly test both the running kernel and the installed xfs_quota binary. But whether or not we should run the test if XGETQSTATV is not present is another question; adding XGETQSTATV fixed a problem of incorrect reporting; if the test fails, we know the environment is not capable of that, and is reporting bad information. So it comes down to whether the test is intended to verify that the "xfs_quota -c state" command is working, or whether the XGETQSTATV interface is working, etc. Generally, we don't restrict test runs to environments where we know the test will pass. So I would say that allowing this to run and fail is the correct option; it tells us that the installed kernel+xfsprogs will report bad information from the "state" command, and that is useful information to the tester. -Eric > + > rm -f $seqres.full > > function option_string() > -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
