[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]