From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vgbcy-00015S-He for qemu-devel@nongnu.org; Wed, 13 Nov 2013 09:41:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vgbcs-0000hE-Jm for qemu-devel@nongnu.org; Wed, 13 Nov 2013 09:41:08 -0500 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:37556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vgbcs-0000gz-CD for qemu-devel@nongnu.org; Wed, 13 Nov 2013 09:41:02 -0500 Received: by mail-lb0-f180.google.com with SMTP id u14so412350lbd.39 for ; Wed, 13 Nov 2013 06:41:01 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131113141924.GF2633@dhcp-200-207.str.redhat.com> 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> From: Fam Zheng Date: Wed, 13 Nov 2013 22:40:30 +0800 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Kevin Wolf Cc: =?UTF-8?Q?Beno=C3=AEt_Canet?= , pbonzini , Fam Zheng , "qemu-devel@nongnu.org" , Stefan Hajnoczi 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