From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgmQz-0004bU-9M for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:13:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgmQq-0002n3-8f for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:13:29 -0500 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:42672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgmQp-0002ml-KK for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:13:20 -0500 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 14 Nov 2013 07:43:11 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 7BCDEE0055 for ; Thu, 14 Nov 2013 07:45:03 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAE2D27F41222346 for ; Thu, 14 Nov 2013 07:43:05 +0530 Received: from d28av02.in.ibm.com (localhost [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAE2D7pf032653 for ; Thu, 14 Nov 2013 07:43:07 +0530 Message-ID: <528431B1.9040608@linux.vnet.ibm.com> Date: Thu, 14 Nov 2013 10:13:05 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1384338584-14065-1-git-send-email-famz@redhat.com> <1384338584-14065-3-git-send-email-famz@redhat.com> <20131113141924.GF2633@dhcp-200-207.str.redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 2/2] qapi: Change BlockDirtyInfo to list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Kevin Wolf Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , pbonzini , Fam Zheng , "qemu-devel@nongnu.org" , Stefan Hajnoczi 于 2013/11/13 22:40, Fam Zheng 写道: > On Wed, Nov 13, 2013 at 10:19 PM, Kevin Wolf wrote: >> Am 13.11.2013 um 11:29 hat Fam Zheng geschrieben: >>> We have multiple dirty bitmaps in BDS now, switch QAPI to allow query >>> it (BlockInfo.dirty_bitmaps), and also drop old BlockInfo.dirty. >>> >>> Signed-off-by: Fam Zheng >> >>> diff --git a/qapi-schema.json b/qapi-schema.json >>> index 81a375b..931d710 100644 >>> --- a/qapi-schema.json >>> +++ b/qapi-schema.json >>> @@ -948,8 +948,8 @@ >>> # @tray_open: #optional True if the device has a tray and it is open >>> # (only present if removable is true) >>> # >>> -# @dirty: #optional dirty bitmap information (only present if the dirty >>> -# bitmap is enabled) >>> +# @dirty-bitmaps: #optional dirty bitmaps information (only present if the >>> +# driver has one or more dirty bitmaps) >>> # >>> # @io-status: #optional @BlockDeviceIoStatus. Only present if the device >>> # supports it and the VM is configured to stop on errors >>> @@ -963,7 +963,7 @@ >>> 'data': {'device': 'str', 'type': 'str', 'removable': 'bool', >>> 'locked': 'bool', '*inserted': 'BlockDeviceInfo', >>> '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus', >>> - '*dirty': 'BlockDirtyInfo' } } >>> + '*dirty-bitmaps': ['BlockDirtyInfo'] } } >>> >>> ## >>> # @query-block: >> >> I believe this is of limited use; if you ever have more than one dirty >> bitmap, we're lacking information to associate it with the job it >> belongs to. One option would be to extend BlockDirtyInfo to indicate >> this, but another might be to actually extend other commands like >> query-block-jobs to return information on the dirty bitmap associated >> with a specific job. >> >> I've applied it to block-next anyway, we still have some time to >> reconsider for 1.8. >> > > Another case for this may be user enabled external dirty bitmap, which > could be standalone from any block job. E.g. when we introduce a QMP > command like: > > block-new-dirty-bitmap device=foo file=bar.bitmap > > This could be some code in block.c, could be a block job (really > necessary?), or a block filter. I'm not sure... > > Fam > This command is for sure useful, but not quite a core block fuction, so hope it would not be in block.c. I think there is another problem need to solve: how to let user read "bar.bitmap", three options here: qemu-img dump, a new qmp command, a library. It seems a library is better(probably qmp interface is also needed).