[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v8 00/36] block: Image locking series

From: Fam Zheng
Subject: Re: [Qemu-block] [PATCH v8 00/36] block: Image locking series
Date: Tue, 25 Oct 2016 15:09:51 +0800
User-agent: Mutt/1.7.0 (2016-08-17)

On Mon, 10/24 12:11, Kevin Wolf wrote:
> Am 22.10.2016 um 03:00 hat Max Reitz geschrieben:
> > <parenthesis>
> > 
> > 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]