On 05/17/2011 12:56 PM, Eric Blake wrote:
On 05/17/2011 12:12 PM, Matthias Bolte wrote:
>
> The actual semantic for (n)params is not completely defined, is it?
> This just matches what (most of?) the driver currently do.
>
>> Hmm, here we document that nparams can be <= the value returned by
>> virDomainGetSchedulerType; which means it can be 0, which means that
>> params can be NULL. I think we should change this to allow NULL,0 in
>> input as a way of querying the proper nparams size on output.
>
> Why would you add a second way to query nparams?
I guess the alternative is to tighten up the documentation to
specifically state that nparams must be the number of parameters (and
not a subset) managed by the device for Get; Set can still do subsets
though.
I went with the documentation alternative in this patch [1], although I
didn't add the explicit NULL checking to the new API functions (neither
in Hu's virDomainSetSchedulerParametersFlags pushed today, nor my
proposed virDomainGetSchedulerParametersFlags in [1]), so depending on
which one gets pushed first, the other patch should probably add some
NULL checking.
[1]
https://www.redhat.com/archives/libvir-list/2011-May/msg01146.html
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org