On 08/27/2015 12:59 PM, John Snow wrote: >> Dan made the point that if a name is unpredictable, then we have >> to query to learn what name was assigned. But if you add two or >> more devices before querying, then you don't know which device has >> which name. Predictable might actually be better than >> non-predictable. >> > > Can we add the information into the QMP response?
Yes, any command that currently returns nothing (aka {}) can be expanded
to return something useful, such as the name of the device just
allocated, without breaking back-compat. That would be one less round
trip (create a device, and the response is the devices name; rather than
create a device and pass a second command to query its name). But
remember that even things as trivial as creating a disk device may open
several BDS and therefore create several named items at once, so we have
to be careful that all the information can be parsed.
On the bright side, Markus' introspection work would let us know if a
command's return struct supplies the additional information. On the
downside, management apps that want to talk to older qemu probably
wouldn't use it anyways, as they have to have the fallback of supplying
a name in the first place for older qemu, at which point supplying the
name always is easier than making code conditional on whether qemu is
new enough to introspect.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
