On 10/25/2011 03:31 PM, Eric Blake wrote:
Here's what I'm squashing in:
Good thing I haven't pushed yet - I just realized another problem.
But on Get interfaces, like virDomainGetMemoryParamaters, params is an output-only interface; it can be uninitialized memory on entry, so we must not base our behavior on the client's contents. Rather, the typed parameter check has to either be done by each the callback (where we write each hypervisor driver to not output strings unless they first check flags), or can be factored into libvirt.c (hypervisors can blindly write back all parameters, then libvirt.c does a post-process pass that shrinks the array size to skip past all string entries).
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. And if that is the case, then each hypervisor driver _has_ to do filtering manually, to return the right *nparams value in the first place - that is, if they ever want to pass back strings. But virDomainGetBlkioParameters, virDomainGetMemoryParameters, and virDomainBlockStatsFlags could be "fixed" to return the number of elements populated, rather than 0. Are we okay making that sort of API change? I'll ask again when I post this as a v5. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org