On Thu, 2018-03-01 at 19:03 +0100, Andrea Bolognani wrote:
@@ -2883,6 +2883,12 @@ virQEMUCapsProbeQMPObjects(virQEMUCapsPtr
qemuCaps,
int nvalues;
char **values;
size_t i;
+ const char *impl = "device-list-properties";
+
+ /* Prefer qom-list-properties if available, since it allows us to gather
+ * information about objects that device-list-properties doesn't support */
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QOM_LIST_PROPERTIES))
+ impl = "qom-list-properties";
if ((nvalues = qemuMonitorGetObjectTypes(mon, &values)) < 0)
return -1;
@@ -2899,9 +2905,7 @@ virQEMUCapsProbeQMPObjects(virQEMUCapsPtr qemuCaps,
if (cap >= 0 && !virQEMUCapsGet(qemuCaps, cap))
continue;
- if ((nvalues = qemuMonitorGetObjectProps(mon,
- type,
- &values)) < 0)
+ if ((nvalues = qemuMonitorGetObjectProps(mon, impl, type, &values)) < 0)
return -1;
I should note that I don't love this approach: I would much rather
pass qemuCaps all the way down to qemuMonitorJSONGetObjectProps()
and make the decision there for better encapsulation.
However, qemu_capabilities depends on qemu_monitor, so that would
introduce a circular dependency and I'm not sure trying to break it
up is worth the effort.
So if anyone fells like weighing in on the subject, or provide
alternative suggestions, I'm all ears.
--
Andrea Bolognani / Red Hat / Virtualization