Re: [PATCH v4 1/2] Add VIR_TYPED_PARAM_STRING

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]