On 10/25/2011 05:51 PM, Eric Blake wrote:
Shoot, we have another problem. The current Get interfaces are
documented as returning 0 on success, rather than the number of
successfully returned elements. virDomainGetSchedulerParameters is
hard-wired in the RPC protocol to not pass an array length, and we
repeated that mistake in virDomainGetSchedulerParamatersFlags. That
means we _can't_ reduce *nparams by doing libvirt.c filtering of the
results.

I stand (somewhat) corrected - the RPC protocol actually carries two length parameters, one built into the params<MAX> notation (used when returning a non-NULL list), and one as int nparams (used when params was NULL on entry, for calculating the hypervisor's max return). So *nparams _is_ updated on return, and can be less on output than it was on input. That said, the qemu driver is rather picky about rejecting calls if *nparams is too small on input, even though it might make sense to allow querying of only the first m elements rather than all n.

I'm still working on improving this patch series, with the goal of getting VIR_TYPED_PARAM_STRING stable in 0.9.7, if we agree that it looks safe enough.

--
Eric Blake   ebl...@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to