From: Eryu Guan <eguan@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, jack@suse.cz
Subject: Re: [PATCH v2 1/2] fstests: introduce _require_no_mount_opts helper
Date: Fri, 24 Jun 2016 12:50:19 +0800 [thread overview]
Message-ID: <20160624045019.GC23649@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20160622230650.GL27480@dastard>
On Thu, Jun 23, 2016 at 09:06:50AM +1000, Dave Chinner wrote:
> On Wed, Jun 22, 2016 at 11:23:51AM +0800, Eryu Guan wrote:
> > On Wed, Jun 22, 2016 at 09:42:02AM +1000, Dave Chinner wrote:
> > > On Tue, Jun 21, 2016 at 06:40:28PM +0800, Eryu Guan wrote:
> > > > Some tests require that there's no certain mount option, so
> > > > introduce a new helper _require_no_mount_opts() to do the check on
> > > > $MOUNT_OPTIONS.
> > >
> > > I think this is fine, except for the name. It's more of an exclude
> > > rule rather than a "require" rule. i.e. _exclude_mount_option() is
> > > closer to it's purpose.
> >
> > This does look better to me, thanks!
> >
> > >
> > > The only other question I have is that mount options can be
> > > different between test and scratch devices - the test device mount
> > > options can be set via TEST_FS_MOUNT_OPTS, as well as via
> > > MOUNT_OPTIONS. Does this rule need to handle that?
> >
> > I didn't think about TEST_FS_MOUNT_OPTS. Currently there's no need to
> > handle it, MOUNT_OPTIONS is sufficient I think.
> >
> > How about I rename it to _exclude_scratch_mount_option()? And we can
> > always add another _exclude_test_mount_option() if needed in future.
>
> Sounds good.
Hi Dave,
My v4 patches simply rename the helper to this
"_exclude_scratch_mount_option", no function change. Then I take your
reviews as a "Reviewed-by" tag based on "I think this is fine, except for
the name." and the above "Sounds good.". So I can queue them for next
pull request and start release testing, and don't have to bother you
providing an explicit reviewed-by.
Please let me know if you have different thoughts.
Thanks,
Eryu
next prev parent reply other threads:[~2016-06-24 4:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 10:40 [PATCH v2 1/2] fstests: introduce _require_no_mount_opts helper Eryu Guan
2016-06-21 10:40 ` [PATCH v2 2/2] ext4/271: _notrun if there are journal related mount options Eryu Guan
2016-06-21 23:42 ` [PATCH v2 1/2] fstests: introduce _require_no_mount_opts helper Dave Chinner
2016-06-22 3:23 ` Eryu Guan
2016-06-22 23:06 ` Dave Chinner
2016-06-24 4:50 ` Eryu Guan [this message]
2016-06-27 0:39 ` Dave Chinner
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=20160624045019.GC23649@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=jack@suse.cz \
/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.