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