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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list