From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: libvir-list@redhat.com, "Ján Tomko" <jtomko@redhat.com>,
qemu-devel@nongnu.org, "Greg Kurz" <groug@kaod.org>
Subject: Re: [PATCH 1/1] conf: qemu 9pfs: add 'multidevs' option
Date: Thu, 19 Mar 2020 16:02:21 +0000 [thread overview]
Message-ID: <20200319160221.GF2322997@redhat.com> (raw)
In-Reply-To: <1876644.SqPMx7qSmg@silver>
On Thu, Mar 19, 2020 at 04:57:41PM +0100, Christian Schoenebeck wrote:
> On Donnerstag, 19. März 2020 14:10:26 CET Ján Tomko wrote:
> > On a Tuesday in 2020, Christian Schoenebeck wrote:
> > >Introduce new 'multidevs' option for filesystem.
> > >
> > > <filesystem type='mount' accessmode='mapped' multidevs='remap'>
> >
> > I don't like the 'multidevs' name, but cannot think of anything
> > beter.
> >
> > 'collisions' maybe?
>
> Not sure if 'collisions' is better, e.g. collisions='remap' sounds scary. :)
> And which collision would that be? At least IMO 'multidevs' is less ambigious.
> I have no problem though to change it to whatever name you might come up with.
> Just keep the resulting key-value pair set in mind:
>
> multidevs='default'
> multidevs='remap'
> multidevs='forbid'
> multidevs='warn'
>
> vs.
>
> collisions='default'
> collisions='remap' <- probably misleading what 'remap' means in this case
> collisions='forbid'
> collisions='warn' <- wrong, it warns about multiple devices, not about file ID
> collisions.
>
> So different key-name might also require different value-names.
>
> Another option would be the long form 'multi-devices=...'
I tried to come up with names when this was posted to QEMU, but didn't
think of much better than multidevs, so I think that's acceptable for
libvirt usage.
"collisions" isn't better enough to justify different naming from QEMU
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-03-19 16:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 16:38 [PATCH 0/1] add support for QEMU 9pfs 'multidevs' option Christian Schoenebeck
2020-03-17 13:59 ` [PATCH 1/1] conf: qemu 9pfs: add " Christian Schoenebeck
2020-03-19 13:10 ` Ján Tomko
2020-03-19 15:57 ` Christian Schoenebeck
2020-03-19 16:02 ` Daniel P. Berrangé [this message]
2020-03-19 16:19 ` Ján Tomko
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=20200319160221.GF2322997@redhat.com \
--to=berrange@redhat.com \
--cc=groug@kaod.org \
--cc=jtomko@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.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.