From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byuPf-0007PR-LT for qemu-devel@nongnu.org; Tue, 25 Oct 2016 01:36:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byuPe-00085u-S2 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 01:36:39 -0400 Date: Tue, 25 Oct 2016 13:36:30 +0800 From: Fam Zheng Message-ID: <20161025053630.GB5427@lemon> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <1475237406-26917-3-git-send-email-famz@redhat.com> <50c03fb7-5016-f6c4-f469-71706e9903da@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50c03fb7-5016-f6c4-f469-71706e9903da@redhat.com> Subject: Re: [Qemu-devel] [PATCH v8 02/36] qapi: Add ImageLockMode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, Kevin Wolf , rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com On Fri, 10/21 22:45, Max Reitz wrote: > On 30.09.2016 14:09, Fam Zheng wrote: > > Signed-off-by: Fam Zheng > > --- > > 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