[ovs-dev] ABI versioning (was Re: [PATCH] rhel: Support...)

Ben Warren ben at skyportsystems.com
Thu Jan 5 17:44:33 UTC 2017


Hi Aaron,

> On Jan 5, 2017, at 7:52 AM, Aaron Conole <aconole at bytheb.org> wrote:
> 
> <snip>
> 
>>>> Should we bump the libtool version now?  We're nearing a release, so
>>>> it's about the right time.
>>> 
>>> Sorry for the late response.  I think it's probably appropriate to bump
>>> at least the libtool 'age'.  I'm not sure what kinds of ABI changes have
>>> happened since introduction though - the interface 'major' version may
>>> need to change.
>> 
>> I'm pretty sure we've busted ABIs left and right since 2014, so a major
>> version update should be appropriate.
> 
> I was about to post a patch that simply bumped this version, but it sent
> me off onto a tangent leading to this question:
> 
> Will Open vSwitch support the libopenvswitch.so as an externally
> linkable library?
> 
Yes, as an example Debian now has a ‘openvswitch-dev’ package that bundles the library and header files.  Here’s how it currently looks (Debian ‘sid’):

ben at ben-lab-sc1:~$ dpkg -c openvswitch-dev_2.6.2-pre+git20161223-2_amd64.deb | grep "lib.*\.so"
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libofproto.so -> libofproto.so.1.0.0
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libopenvswitch.so -> libopenvswitch.so.1.0.0
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libovn.so -> libovn.so.1.0.0
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libovsdb.so -> libovsdb.so.1.0.0
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libsflow.so -> libsflow.so.1.0.0
lrwxrwxrwx root/root         0 2016-12-23 16:35 ./usr/lib/libvtep.so -> libvtep.so.1.0.0

> I know there was some work done in this direction, but nothing for ABI
> versioning or API compatibility has been done yet.
> 
As you can see, the library naming isn’t very useful.  As for ABI versioning, I don’t think anything meaningful has been done.  IMHO we should probably change this so the major release is part of the name, since that’s where I believe we should guarantee compatibility, along the l lines of ‘libopenvswitch_2.5.so’ or whatever.  I think there are libtool directives for managing this naming, but we haven’t done that.

> I've CCd folks who were on the original discussions for the various
> series I've found (linked below).
> 
> I'm uncomfortable with bumping this and just 'let the chips fall where
> they may,' since having a version that hasn't changed is the virtually
> the same as not having a version.  The instant we bump, we state that
> the version means something, so I'm not comfortable just shipping a
> patch that changes the version without some accompanying documentation
> explaining *what* that means.  It also means we need to be more diligent
> with reviews and watch for potential ABI breakages, with a compatibility
> strategy in place (when ABI/API changes can be made, how they are made,
> etc.).  I think it's got more implication than just a single line change
> to the configure.ac file.
> 
> Below are a few snippets I found;  there may be more discussions I've
> missed, so please feel free to include links (or summaries).
> 
> Versioning patch (which mentions that it isn't yet intended to be for
>  3rd party linking):
>  https://mail.openvswitch.org/pipermail/ovs-dev/2014-November/291959.html
> 
> The first non-rfc 'third-party linking' series I could find (with note
>  from Panu at least warning about this):
>  https://mail.openvswitch.org/pipermail/ovs-dev/2016-March/310703.html
>  https://mail.openvswitch.org/pipermail/ovs-dev/2016-March/310773.html
> 
> The series 'third party linking' series has all parts accepted:
>  https://mail.openvswitch.org/pipermail/ovs-dev/2016-April/313183.html
> 
> -Aaron



More information about the dev mailing list