From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byvs0-0002nV-Tf for qemu-devel@nongnu.org; Tue, 25 Oct 2016 03:10:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byvs0-0007Io-02 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 03:10:00 -0400 Date: Tue, 25 Oct 2016 15:09:51 +0800 From: Fam Zheng Message-ID: <20161025070951.GF5427@lemon> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024101111.GB4374@noname.redhat.com> Subject: Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Max Reitz , qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com On Mon, 10/24 12:11, Kevin Wolf wrote: > Am 22.10.2016 um 03:00 hat Max Reitz geschrieben: > > > > > > I personally still don't like making locking a qdev property very much > > because it doesn't make sense to me*. But I remember Kevin had his > > reasons (even though I can no longer remember them) for asking for it, > > and I don't have any besides "It doesn't make sense to me". After having > > though a bit about it (= having written three paragraphs and deleted > > them again), I guess I can make some sense of it, though it seems to be > > a rather esoteric use case still; it appears to me that a guest could > > use it to signal that it's fine with some block device being shared; > > then we could use a shared lock or none at all or I don't know. > > Otherwise, we should get an exclusive lock for write access and a shared > > lock for read access. > > The reason is pretty simple if you think about this question: Why do we > need user input in the first place? I think the reason why we have an option at all is rather because of the special case of libguestfs [1], otherwise locks should just be acquired sensibly as the "auto" mode does. Other than that, I don't think we have a concrete use case of non-auto lock mode. Do we? [1]: https://lists.nongnu.org/archive/html/qemu-block/2016-04/msg00414.html Fam