δΊ 2013/11/13 22:40, Fam Zheng ει:
On Wed, Nov 13, 2013 at 10:19 PM, Kevin Wolf <kw...@redhat.com> 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 <f...@redhat.com>
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).