On Wed, Feb 16, 2022 at 02:44:52PM +0100, Markus Armbruster wrote: > > > > +## > > +# @NbdExportMultiConn: > > +# > > +# Possible settings for advertising NBD multiple client support. > > +# > > +# @off: Do not advertise multiple clients. > > +# > > +# @on: Allow multiple clients (for writable clients, this is only safe > > +# if the underlying BDS is cache-consistent, such as when backed > > +# by the raw file driver); ignored if the NBD server was set up > > +# with max-connections of 1. > > +# > > +# @auto: Behaves like @off if the export is writable, and @on if the > > +# export is read-only. > > +# > > +# Since: 7.0 > > +## > > +{ 'enum': 'NbdExportMultiConn', > > + 'data': ['off', 'on', 'auto'] } > > Have you considered using OnOffAuto from common.json?
Sounds good to me. > > Duplicating it as NbdExportMultiConn lets you document the values right > in the enum. If you reuse it, you have to document them where the enum > is used, i.e. ... > > > + > > ## > > # @BlockExportOptionsNbd: > > # > > @@ -95,11 +119,15 @@ > > # the metadata context name "qemu:allocation-depth" to > > # inspect allocation details. (since 5.2) > > # > > +# @multi-conn: Controls whether multiple client support is advertised, if > > the > > +# server's max-connections is not 1. (default auto, since 7.0) > > +# > > ... here. Yep, that's a good change to make for v3. I'll do it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org