From: Karel Zak <kzak@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Eryu Guan <eguan@redhat.com>, fstests <fstests@vger.kernel.org>,
"Misono, Tomohiro" <misono.tomohiro@jp.fujitsu.com>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH v4] fstests: filter readonly mount error messages
Date: Mon, 27 Nov 2017 11:54:25 +0100 [thread overview]
Message-ID: <20171127105425.zxcgjo5eju6azj5u@ws.net.home> (raw)
In-Reply-To: <CAOQ4uxjbnrgJG3PLVV6TvAS-Fjgskms_jWc5-b4DVmLhbVUdFg@mail.gmail.com>
On Sun, Nov 26, 2017 at 10:56:40AM +0200, Amir Goldstein wrote:
> >> Thinking out loud, does xfstest even need to use mount program from
> >> util-linux? Do we ever need anything other than the bare libc mount(2)?
> >> We need it for -o loop, but that is the exception to the rule.
> >
> > Well, I don't think that create a parallel universe is the best
> > solution.
> >
>
> I agree. However, xfstest uses 'mount' is a very particular way:
> - User has to provide both block device and mount point
> - xfstests already checks that those block device and mount point
> are not in use in /proc/mounts *before* calling 'mount'
OK, I see, than the wrapper is not so bad idea (if you're able to keep
it simple and stupid:-)
> So I prefer the 'machine output format' solution going forward, but
> since xfstests will need to continue supporting old util-linux installations
> it might be less clumsy to use a simple C wrapper to mount(2), then
> to carry these error format filters.
> xfstests can also check for availability of the new machine format in
> 'mount' and if it doesn't exist fall back to using its private mount helper.
If you want to implement the wrapper than it's probably better use it
in all cases and then you can remove all the backward compatibility
filters. In thins case it seems better to depend on the wrapper only.
So, the unified messages maintained by unit-linux mount(8) will be
unnecessary.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2017-11-27 10:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 11:10 [PATCH v3 0/3] fix failures caused by mount error msg change in util-linux v2.30 Eryu Guan
2017-11-23 11:10 ` [PATCH v3 1/3] fstests: filter mount error message for EUCLEAN and ESTALE Eryu Guan
2017-11-23 11:10 ` [PATCH v3 2/3] overlay/036: filter busy mount message Eryu Guan
2017-11-23 11:10 ` [PATCH v3 3/3] fstests: filter readonly mount error messages Eryu Guan
2017-11-23 13:28 ` Amir Goldstein
2017-11-23 13:34 ` Amir Goldstein
2017-11-23 14:09 ` Eryu Guan
2017-11-24 5:01 ` [PATCH v4] " Eryu Guan
2017-11-24 8:04 ` Amir Goldstein
2017-11-24 10:38 ` Karel Zak
2017-11-26 8:56 ` Amir Goldstein
2017-11-27 10:54 ` Karel Zak [this message]
2017-11-28 7:52 ` Eryu Guan
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=20171127105425.zxcgjo5eju6azj5u@ws.net.home \
--to=kzak@redhat.com \
--cc=amir73il@gmail.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=misono.tomohiro@jp.fujitsu.com \
/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.