On Fri, 10/21 22:45, Max Reitz wrote:
> On 30.09.2016 14:09, Fam Zheng wrote:
> > Signed-off-by: Fam Zheng <f...@redhat.com>
> > ---
> > qapi/block-core.json | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 92193ab..22e8d04 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -2754,3 +2754,21 @@
> > 'data' : { 'parent': 'str',
> > '*child': 'str',
> > '*node': 'str' } }
> > +
> > +##
> > +# @ImageLockMode:
> > +#
> > +# @auto: defer to the block driver to use the least strict mode, based on
> > +# the nature of format and read-only flag, and the supported locking
> > +# operations of the protocol.
>
> I have some difficulty understanding this description. I'd intuitively
> assume no locking to be the "least strict mode"; however, since it
> should be always possible not to lock an image, this would mean that
> auto=nolock. Which is hopefully isn't.
>
> If it's not easy to come up with a thorough explanation, perhaps it
> would be best to give some examples which help to understand the concept
> behind "auto" intuitively.
It could have beeen more specific, it's my bad being too terse here. Maybe
something like this:
@auto: defer to the block layer to use an appropriate lock mode, based on
the driver used and read-only option: for read-only images, shared
lock mode, or otherwise exclusive lock mode, will be attempted; if
the driver doesn't support this mode (or sharing is particularly
desired by its design), nolock will be used.
?
Fam
