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