From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgmaO-00072f-HF for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:23:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgmaI-0005VX-Fn for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:23:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgmaI-0005VT-7c for qemu-devel@nongnu.org; Wed, 13 Nov 2013 21:23:06 -0500 Message-ID: <52843400.5010103@redhat.com> Date: Thu, 14 Nov 2013 10:22:56 +0800 From: Fam Zheng 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> <528431B1.9040608@linux.vnet.ibm.com> In-Reply-To: <528431B1.9040608@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Wenchao Xia , Kevin Wolf Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , pbonzini , Fam Zheng , "qemu-devel@nongnu.org" , Stefan Hajnoczi On 2013=E5=B9=B411=E6=9C=8814=E6=97=A5 10:13, Wenchao Xia wrote: > =E4=BA=8E 2013/11/13 22:40, Fam Zheng =E5=86=99=E9=81=93: >> 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 quer= y >>>> 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 op= en >>>> # (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 erro= rs >>>> @@ -963,7 +963,7 @@ >>>> 'data': {'device': 'str', 'type': 'str', 'removable': 'bool', >>>> 'locked': 'bool', '*inserted': 'BlockDeviceInfo', >>>> '*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatu= s', >>>> - '*dirty': 'BlockDirtyInfo' } } >>>> + '*dirty-bitmaps': ['BlockDirtyInfo'] } } >>>> >>>> ## >>>> # @query-block: >>> >>> I believe this is of limited use; if you ever have more than one dirt= y >>> 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=3Dfoo file=3Dbar.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). > Yes, block.c is certainly too ad hoc and I don't like it either. I didn't go deep into this yet, I think we need to discuss these in a=20 separate thread. Indeed there's much to decide: where the code lies,=20 what format we would use and how to ensure consistency, etc. Fam