From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org,
"Antonios Motakis" <antonios.motakis@huawei.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions
Date: Mon, 23 Sep 2019 18:50:12 +0200 [thread overview]
Message-ID: <20190923185012.06131248@bahia.lan> (raw)
In-Reply-To: <7439377.rdf1oF7g69@silver>
On Mon, 23 Sep 2019 17:03:23 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Montag, 23. September 2019 16:46:53 CEST Greg Kurz wrote:
> > > > > > I'll do some
> > > > > > more manual testing and issue a PR when I'm confident enough.
> > > > >
> > > > > That would be highly appreciated! So far I am the only one ever having
> > > > > tested this patch set at all!
> > > >
> > > > Just to clarify, I won't thoroughly test it. My main concern is that it
> > > > doesn't break things.
> > >
> > > So in other words you are only going to test the default behaviour
> > > --multidevs=warn?
> >
> > This I've already done, along with multidevs=forbid.
> >
> > Now I plan to run the PJD test suite from Tuxera with a simple
> > cross-device setup and --multidevs=remap. And that's it.
>
> Well, Ok then, however at least some simple, manual, final "ls -i" of the
> inode numbers on guest would not hurt though. ;-)
>
> > > If yes, and since that would mean I was the only person ever having tested
> > > the actual fix, shouldn't --multidevs=remap|forbid better be marked as
> > > experimental (docs and runtime warning) for now? Maybe that would also
> > > anticipate receiving feedback from people actually using it later on.
> > Makes sense. I don't think it is worth having a runtime warning,
> > but I'll turn remap to x-remap and amend the docs.
>
> Mwa, I would like to veto against your "x-remap" plan though. Keep in mind I
> also have to send out a patch for libvirt for this fix. Even I would not have
> read "x" to stand for "experimental". So I would definitely favor a runtime
> warning instead of renaming that parameter.
>
Hmmm... I don't see the point in adding a warning for a feature that
is only active if the user explicitly asks for it. And, anyway, this
still is an experimental feature, right ? Not sure it is time to have
libvirt to support it yet.
Maybe Daniel can comment on libvirt adoption of new features ?
> I can send a patch on top for docs and warning if you want.
>
>
next prev parent reply other threads:[~2019-09-23 16:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 10:42 [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-09-04 21:34 ` [Qemu-devel] [PATCH v7 1/3] 9p: Added virtfs option 'multidevs=remap|forbid|warn' Christian Schoenebeck via Qemu-devel
2019-09-04 22:05 ` [Qemu-devel] [PATCH v7 2/3] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-09-04 22:53 ` [Qemu-devel] [PATCH v7 3/3] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-09-13 17:01 ` [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Greg Kurz
2019-09-23 9:50 ` Christian Schoenebeck via
2019-09-23 12:56 ` Greg Kurz
2019-09-23 14:06 ` Christian Schoenebeck via
2019-09-23 14:46 ` Greg Kurz
2019-09-23 15:03 ` Christian Schoenebeck via
2019-09-23 16:50 ` Greg Kurz [this message]
2019-09-24 9:31 ` Christian Schoenebeck via
2019-10-08 9:14 ` Greg Kurz
2019-10-08 12:05 ` Christian Schoenebeck
2019-10-08 13:47 ` Greg Kurz
2019-10-08 14:25 ` Christian Schoenebeck
2019-10-08 14:45 ` Greg Kurz
2019-10-15 9:20 ` Greg Kurz
2019-10-16 9:42 ` virtio-fs: Fix file ID collisions (was: 9p: Fix file ID collisions) Christian Schoenebeck
2019-10-16 13:44 ` Dr. David Alan Gilbert
2019-10-18 13:15 ` Christian Schoenebeck
2019-10-16 14:00 ` Greg Kurz
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=20190923185012.06131248@bahia.lan \
--to=groug@kaod.org \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@gmail.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.