From: David Howells <dhowells@redhat.com>
To: Eryu Guan <eguan@redhat.com>
Cc: dhowells@redhat.com, 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 11:46:29 +0100 [thread overview]
Message-ID: <11252.1490957189@warthog.procyon.org.uk> (raw)
In-Reply-To: <20170331101941.GL22845@eguan.usersys.redhat.com>
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).
> > +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.
> 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.
> ... 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.
> 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)?
> 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?
> > +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.
David
next prev parent reply other threads:[~2017-03-31 10:46 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 [this message]
2017-03-31 11:23 ` Eryu Guan
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=11252.1490957189@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=adilger@dilger.ca \
--cc=eguan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).