[libvirt] cpu flags

[Daniel P. Berrange]

On Wed, Sep 17, 2008 at 08:36:50AM -0400, Konrad Rzeszutek wrote:
> On Wed, Sep 17, 2008 at 11:43:19AM +0100, Richard W.M. Jones wrote:
> > 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.
> > 
> > <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
> 
> How about just having a virVersion field that would tell you what
> version of the struct it is? This being on top of the check you have.
> 
> That way you can also guard against functions that change the number of
> arguments, which would not change the size of the caller's structure.

I don't want us playing tricks with ABI based on the version number.

It is quite easy to add new structs & APIs to the public interface without
breaking ABI of existing structs & APIs.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|