All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>,
	Andreas Dilger <adilger@dilger.ca>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, Eric Sandeen <sandeen@sandeen.net>,
	fstests@vger.kernel.org
Subject: Re: [PATCH] xfstests: Add first statx test
Date: Fri, 31 Mar 2017 19:23:04 +0800	[thread overview]
Message-ID: <20170331112304.GM22845@eguan.usersys.redhat.com> (raw)
In-Reply-To: <11252.1490957189@warthog.procyon.org.uk>

On Fri, Mar 31, 2017 at 11:46:29AM +0100, David Howells wrote:
> Eryu Guan <eguan@redhat.com> wrote:
> 
> > Also, we need to detect if the filesystem in test supports statx(2) or
> > not, and call _notrun to exit immediately and skip the test, so test
> > doesn't fail when running on older kernels where don't have statx
> > support. e.g. a new _require rule like
> 
> All filesystems support statx.  What changes is whether they provide any extra
> data.  What does matter is the kernel version (4.11-rc1 minimum).

xfstests is run not only with latest upstream kernel, but also with many
distro kernels, like RHEL, by distro testers, where there's no statx
syscall support at all (at this moment). So test should _notrun instead
of failing there.

If not providing extra data will fail the test, we need to require the
filesystem to be tested to provide such extra data too.

> 
> > > +failed=0
> > 
> > This is not needed, "status" is sufficient.
> 
> The script generated by new says:
> 
> 	status=1	# failure is the default!
> 
> I presume I'm allowed to change the default.

Yes, you can change the default simply by "status=0". But in xfstests we
rarely do that, we usually set status=0 just before exit if everything
went well.

> 
> > No need to check if mkfifo's status (and all later similar commands like
> > mkmod, mkdir, ln etc.). ...
> 
> But there's no point doing the stat on them if they didn't succeed.

Then just let statx(2) fail and complain about the missing file, the
test fails anyway. The whole point is that with golden image matching,
you don't have to check return value of every command, that's the
methodology xfstests has adopted. And occasionally, exercising such
error paths help find unexpected bugs too :)

> 
> > ... The test harness compares the test output with the predefined golden
> > output file (420.out in this case) and fails the test if the output doesn't
> > match. So any error message from mkfifo, mknod, mkdir commands will break
> > golden image and fails the test.
> 
> The status variable would be redundant then.

Some tests can't rely on the golden image match, they rely on status
variable. So test passes only if a) golden image matches, b) status=0

> 
> > And prefix or suffix the test file name with current test sequence
> > number would be good, to avoid file name conflicts with test files from
> > other tests.
> 
> Do I increment this for each use?  Or is it per call of the test script?  Or
> is it the number of the script (ie. 420 in this case)?

There's a pre-defined $seq variable (as showed in my example, not
included in this reply), you can just use $seq directly.

> 
> > If nc is really needed, we should check the existence of it before
> > starting the actual test, so test won't fail because of lack of nc
> > command. i.e. define NC_PROG in common/config and call _require_command
> > to check the existence of it. e.g.
> 
> Then I run $NC_PROG rather than nc?

Yes, that's perferred.

> 
> > > +if [ $failed = 1 ]
> > > +then
> > > +    echo "Test script failed"
> > > +    exit
> > > +fi
> > 
> > This is not needed either.
> 
> You're looking at version 1.  This is gone in version 2.
> 
> > I noticed you've already updated group to 'auto quick' :)
> 
> Someone needs to fix ./new.  Also it would be good if ./new either didn't
> require the suite to be built or explicitly said that the suite should be
> built before running if you run it without doing so first.

Yes, and the document really should be improved, so people could have an
easy start with it.

Thanks,
Eryu

  reply	other threads:[~2017-03-31 11:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 16:32 [PATCH] xfstests: Add first statx test David Howells
2017-03-30 18:36 ` Amir Goldstein
2017-03-30 18:45   ` Amir Goldstein
2017-03-31  9:14   ` David Howells
2017-03-30 19:31 ` David Howells
2017-03-31 10:19 ` Eryu Guan
2017-03-31 10:46 ` David Howells
2017-03-31 11:23   ` Eryu Guan [this message]
2017-03-31 12:05 ` David Howells
2017-03-31 12:13   ` Eryu Guan
2017-03-31 13:58   ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170331112304.GM22845@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=dhowells@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.