On 01/16/2012 06:01 AM, Cole Robinson wrote:
On 01/13/2012 02:11 PM, Eric Blake wrote:
I previously proposed this here: https://www.redhat.com/archives/libvir-list/2011-December/msg00899.html although it's been on my wish list a lot longer than that.
Questions: I had the new API take nformats as an int, and return the number of populated slots; should I switch this to take *nformats as a pointer (being both input and output) with a return value of 0, so as to be more consistent with things like virDomainGetMemoryParameters?
I'm not very familiar with writing python bindings, at least not without the benefit of copy-and-paste, and I didn't see a good example to copy from. Ultimately, I envision that the python API will be something like virConnect.domainNativeFormats(self, flags), with a return being a python list of strings (where the underlying code calls virConnectDomainNativeFormats twice, once to determine the list size, and once to determine the list contents), but I'm not sure how to go about doing that (I don't know if generator.py can do it, or if it needs an override, or what). So I left the python bindings undone, and would appreciate if someone else can step in and help.
Hmm, why not just include this info in capabilities XML? Might not be as easy for some simple apps like virsh to consume, but it seems like more of the proper place to put this.
(sorry if this has been discussed before, I haven't been following libvirt-list too closely as of late).
Hmm, good idea. We already use capabilities to expose the list of supported migration URIs, so I'll see about re-spinning this patch into one that adds the supported names as capabilities, then teaches virsh domxml-formats to do an XPath scrape of the capabilities XML rather than needing a new API. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org