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