[libvirt] [PATCH v4 1/2] Add VIR_TYPED_PARAM_STRING

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org