From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34527)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1Z7ajE-0000ey-U2
	for qemu-devel@nongnu.org; Tue, 23 Jun 2015 22:47:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1Z7ajD-00071r-Pv
	for qemu-devel@nongnu.org; Tue, 23 Jun 2015 22:47:56 -0400
Date: Wed, 24 Jun 2015 10:47:47 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20150624024747.GC1264@ad.nay.redhat.com>
References: <1433215322-23529-1-git-send-email-famz@redhat.com>
	<1433215322-23529-3-git-send-email-famz@redhat.com>
	<20150616160736.GD4958@stefanha-thinkpad.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150616160736.GD4958@stefanha-thinkpad.redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 02/13] block: Introduce
 bdrv_lock and bdrv_unlock API
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On Tue, 06/16 17:07, Stefan Hajnoczi wrote:
> On Tue, Jun 02, 2015 at 11:21:51AM +0800, Fam Zheng wrote:
> > +/**
> > + * bdrv_lock:
> > + *
> > + * Begin a temporary exclusive accessing by locking the BDS.
> > + */
> > +void bdrv_lock(BlockDriverState *bs);
> > +
> > +/**
> > + * bdrv_unlock:
> > + *
> > + * End a exclusive accessing.
> > + */
> > +void bdrv_unlock(BlockDriverState *bs);
> 
> This documentation is missing important points:
> 
> 1. Does AioContext need to be held by the caller?  (Yes)

Yes.

> 
> 2. Is this about thread safety?  (No, it's about exclusive access to a
>    BDS *within* the AioContext.)

As it has to quiesce iothreads as well (for now it's even more urgent than
exclusive access within the same AioContext), I'd rather take it as yes.

Paolo, please correct me.

BTW, is there any semantics in here that we can use for multiqueue block layer?

Fam