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

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

 




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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]