[libvirt] [PATCH 2/9] Define the internal driver API for vol wiping

[Daniel P. Berrange]

On Wed, Mar 17, 2010 at 05:31:07PM -0600, Eric Blake wrote:
> On 03/15/2010 08:13 PM, David Allan wrote:
> > @@ -791,6 +795,7 @@ struct _virStorageDriver {
> >      virDrvStorageVolCreateXML volCreateXML;
> >      virDrvStorageVolCreateXMLFrom volCreateXMLFrom;
> >      virDrvStorageVolDelete volDelete;
> > +    virDrvStorageVolWipe volWipe;
> >      virDrvStorageVolGetInfo volGetInfo;
> >      virDrvStorageVolGetXMLDesc volGetXMLDesc;
> >      virDrvStorageVolGetPath volGetPath;
> 
> Any reason this was introduced in the middle of the struct, rather than
> at the end?  Sticking stuff in the middle tends to be asking for
> off-by-one shifts of all the remaining elements in the struct,
> especially if you ever mix objects compiled across the time when the
> element was added.  Whereas always sticking new entries at the end
> allows you to maintain a measure of back-compatibility, where an older
> object still fits in the first half of the struct, and given enough
> version/sizing information, a newer server can correctly assume that
> struct members beyond a given offset are effectively null when talking
> to a client that was compiled against the older struct definition.

This is purely internal code, so there's no compatability issues with
struct member placement in this case.

The only files where we have to be careful for ABI compatability
are include/libvirt/*.h and src/remote/remote_protocol.x (RPC wire format)

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