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