Re: [libvirt] cpu flags

On Tue, Sep 16, 2008 at 04:45:09PM -0400, Ben Guthro wrote: Extending this structure would break the A _B_ I. <aside> Specifically, because of dynamic linking you can have two situations arising: (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. http://libvirt.org/html/libvirt-libvirt.html#virDomainInterfaceStats 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. </aside> 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). http://libvirt.org/html/libvirt-libvirt.html#virConnectGetCapabilities There shouldn't be any API or ABI problems if you extend the capabilities. If you're returning text strings in the capabilities XML then it presumably will also work on ppc and other architectures. Rich. -- 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. http://et.redhat.com/~rjones/virt-top