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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
