[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/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

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