[libvirt] [PATCH 1/4] latency: Introduce new members for _virDomainBlockStats

[Eric Blake]

On 08/18/2011 08:40 AM, Adam Litke wrote:
>> The following libvirt interfaces take a flags parameter, and could be
>> extensible by setting a flag bit that says a larger struct is in use:
>> virDomainGetControlInfo
>> virNodeGetCPUStats
>> virNodeGetMemoryStats
>> virDomainMemoryStats
>
> virDomainMemoryStats() was designed to be regularly extended by using
> the 'nr_stats' parameter.

Oh, right.  In my audit, I forgot that virNodeMemoryStats is a subset of 
virTypedParameter (it's hard-coded to long long stats only); any call 
that uses the virTypedParameter paradigm is extensible by adding more 
name-value (or name-type-value) tuples.  Still, virNodeGetMemoryStats 
has a flags argument, so if we ever come up with a memory stat that is 
better represented as a different type than long long, we could use the 
flag bit to state that virTypedParameter is in use instead.

 >  When I added this API, we had this discusson
> and the design emerged specifically for the kind of extension being
> discussed here.  If a newer client talks to an older server, the effect
> is that the client asks for more stats than are available.  The old
> server simply returns the stats it knows about.  Wouldn't this be the
> best approach to use for block stats as well?  Am I missing a downside
> to the virDomainMemoryStats() approach?

No, other than the fact that it is using its own name-value pair instead 
of reusing the more generic name-type-value tuple of virTypedParameter, 
but I recall that we discussed that at the time and agreed to use of a 
less generic type.

And your question is precisely the tradeoff we're discussing for 
virDomainBlockStats - do we reuse the function call as is with a larger 
size, or do we add a new function?  And if we add a new function, do we 
follow the virTypedParameter/virNodeMemoryStats paradigm of arbitrarily 
long name-[type-]value listings, or do we follow the paradigm of passing 
back a struct with every known value?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org