From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXPwy-00005k-95 for qemu-devel@nongnu.org; Tue, 08 Apr 2014 02:56:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXPws-0006oi-2G for qemu-devel@nongnu.org; Tue, 08 Apr 2014 02:56:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXPwr-0006oZ-P0 for qemu-devel@nongnu.org; Tue, 08 Apr 2014 02:55:57 -0400 Date: Tue, 8 Apr 2014 14:56:01 +0800 From: Fam Zheng Message-ID: <20140408065601.GB11793@T430.redhat.com> References: <1394436370-8908-1-git-send-email-famz@redhat.com> <1394436370-8908-3-git-send-email-famz@redhat.com> <20140406234904.GA7120@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140406234904.GA7120@localhost.localdomain> Subject: Re: [Qemu-devel] [PATCH v17 02/14] block: Introduce op_blockers to BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: kwolf@redhat.com, benoit.canet@irqsave.net, rjones@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, ptoscano@redhat.com, imain@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On Sun, 04/06 19:49, Jeff Cody wrote: > On Mon, Mar 10, 2014 at 03:25:58PM +0800, Fam Zheng wrote: > > BlockDriverState.op_blockers is an array of lists with BLOCK_OP_TYPE_MAX > > elements. Each list is a list of blockers of an operation type > > (BlockOpType), that marks this BDS as currently blocked for a certain > > type of operation with reason errors stored in the list. The rule of > > usage is: > > > > * BDS user who wants to take an operation should check if there's any > > blocker of the type with bdrv_op_is_blocked(). > > > > * BDS user who wants to block certain types of operation, should call > > bdrv_op_block (or bdrv_op_block_all to block all types of operations, > > which is similar to the existing bdrv_set_in_use()). > > > > * A blocker is only referenced by op_blockers, so the lifecycle is > > managed by caller, and shouldn't be lost until unblock, so typically > > a caller does these: > > > > - Allocate a blocker with error_setg or similar, call bdrv_op_block() > > to block some operations. > > - Hold the blocker, do his job. > > - Unblock operations that it blocked, with the same reason pointer > > passed to bdrv_op_unblock(). > > - Release the blocker with error_free(). > > Is there a reason to assume there will be atypical usages that don't > follow these steps? If not, could the Error reason resource be > allocated inside the block() operation if non-NULL, and freed inside > the unblock() operations? Could work as well. It's just that the current interface is following the style of migration blocker. Thanks, Fam