On 05/09/2011 11:09 AM, Daniel P. Berrange wrote:
int virDomainBlockStreamInfo(virDomainPtr dom, const char *device, virBlockStreamInfoPtr info);Any reason you didn't just use the existing 'virDomainJobInfoPtr' struct, with this new API ? In particular I think we want many of the other fields from that struct beyond just 'remaining'.
I'm a bit sad to see that the libvirt API has diverged so much from the QEMU API. I really see no reason to have a fancy mapping layer here. We should pick and API that works for both of us and then implement it in both layers.
In QEMU, we use an iterator based API. This is because we don't want users providing specific offsets and sizes because, quite frankly, there's no way they can choose good values. It's much more complicated and far less efficient to stream in anything but the cluster size of the image. And figuring this out is pretty much beyond even sophisticated consumers.
So other than reporting progress as a fractional percentage, is there really a compelling reason to not have an iterator API in libvirt? If so, we should also revisit the QEMU side of this API.
Regards, Anthony Liguori
Regards, Daniel
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list