Re: [PATCH] xfs/263: skip test if Q_XGETQSTATV hasn't been supported by kernel or xfsprogs

[Xiao Yang <yangx.jy@cn.fujitsu.com>]

On 2016/09/09 21:15, Eric Sandeen wrote:
> On 9/9/16 3:47 AM, Xiao Yang wrote:
>> Signed-off-by: Xiao Yang<yangx.jy@cn.fujitsu.com>
>> ---
>>   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
>
Thanks for your suggestion, i got it.

Thanks,
Xiao Yang
>> +
>>   rm -f $seqres.full
>>
>>   function option_string()
>>
>
> .
>