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