Re: [libvirt] [PATCH 1/4] latency: Introduce new members for _virDomainBlockStats
On 08/17/2011 12:15 PM, Eric Blake wrote:
I just audited libvirt.c, and found that the following libvirt
interfaces that take a size parameter, and could be extensible by use of
the size field:
virDomainBlockStats
virDomainInterfaceStats
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. 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?
virDomainGetBlockInfo
virDomainGetBlockJobInfo
Meanwhile, the following APIs which take a pointer to a struct are
non-extensible (neither size nor flags as an escape hatch to indicate
explicit use of a larger struct), extending any of these would require a
new API function:
virDomainGetInfo
virNodeGetInfo
virDomainGetVcpus
virDomainGetSecurityLabel
virDomainGetSecurityModel
virStoragePoolGetInfo
virStorageVolGetInfo
virDomainGetJobInfo
--
Adam Litke
IBM Linux Technology Center