On 9/26/19 11:05 AM, Peter Krempa wrote:
Rather than generating the transaction contents in random places add a
unified set of APIs to generate the contents for a 'transaction' for the
dirty bitmap APIs.
Signed-off-by: Peter Krempa <pkre...@redhat.com>
---
src/qemu/qemu_monitor.c | 48 ++++++++++++++++++++++++
src/qemu/qemu_monitor.h | 24 ++++++++++++
How much longer do we have to keep qemu_monitor.h? I guess as long as
we still use savevm over HMP. Oh well, not the problem to be solving now.
src/qemu/qemu_monitor_json.c | 71 ++++++++++++++++++++++++++++++++++++
src/qemu/qemu_monitor_json.h | 24 ++++++++++++
I also wonder if we could reduce a LOT of duplication by having
qemu_monitor.h declare typedefs, and then qemu_monitor_json.c populate a
structure with function pointers, rather than having to declare every
function in two .h files. It doesn't reduce the fact that we have to
implement everything in two .c files, but 3 files would be slightly
nicer than 4 for every monitor addition. Again, not necessarily the
problem to be solving now.
+
+int
+qemuMonitorJSONTransactionBitmapRemove(virJSONValuePtr actions,
+ const char *node,
+ const char *name)
+{
+ return qemuMonitorJSONTransactionAdd(actions,
+ "block-dirty-bitmap-remove",
+ "s:node", node,
+ "s:name", name,
+ NULL);
+}
+
This one is not in qemu 4.1. I guess that's why you're trying to depend
on that feature, even though I still think it is possible to use
non-atomic removal (which does not affect correctness of remaining
bitmaps) even though the resulting cleanup is more complex.
Reviewed-by: Eric Blake <ebl...@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
