[libvirt] cpu flags

Richard W.M. Jones rjones at redhat.com
Wed Sep 17 10:43:19 UTC 2008

On Tue, Sep 16, 2008 at 04:45:09PM -0400, Ben Guthro wrote:
> My concern is that adding to the nodeinfo struct breaks the API - such  
> that the structs will be different sizes between versions.

Extending this structure would break the A _B_ I.


Specifically, because of dynamic linking you can have two situations

 (1) caller compiled against old libvirt links to newer libvirt
 (2) caller compiled against new libvirt links to older libvirt

You cannot tell just from the pointer passed to virNodeGetInfo how
large the caller's structure is, so you could end up overwriting
memory beyond the structure in case (1).

In calls such as virDomainInterfaceStats, I fixed this by having the
caller pass both a pointer to the structure and the size of the
caller's structure.  This allows us to expand the structure in future
in a way which won't break either case (1) or (2).  I would encourage
people designing future libvirt APIs which take a pointer to a
structure, to also get the caller to pass the size of the structure.


Another way to solve this, less elegant I think, is to have callers
explicitly say "I was compiled for libvirt 0.4.5" when they connect,
and then we can tell what size of structure they are expecting.  This
is somewhat analogous to the Linux personality(2) system call.


In any case, I think the best place to return the flags is in the
capabilities XML as simple text strings (the same strings as are used
in /proc/cpuinfo).


There shouldn't be any API or ABI problems if you extend the

> Also - this seems to be x86 specific. Are we primarily destined for x86?  
> Or would this type of change be unacceptable due to not working on PPC,  
> for example?

If you're returning text strings in the capabilities XML then it
presumably will also work on ppc and other architectures.


Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.

More information about the libvir-list mailing list