[ovs-dev] [PATCH v2 00/23] RFC: rework code base for third-party linking

Panu Matilainen pmatilai at redhat.com
Fri Mar 4 08:57:20 UTC 2016


On 03/03/2016 08:20 PM, ben at skyportsystems.com wrote:
> From: Ben Warren <ben at skyportsystems.com>
>
> This patch set is a first stab at making a 'dev' distribution for OpenVswitch
> The goal is to provide shared libraries and header files so that third party
> applications can link in OVS rather than always using the command line
> utilities.

Cool. I didn't look at the details of the patch-set (yet) but a few 
general comments below.

>
> Changes in V2:
> - Work to move all of ofp-util to public include directory
> - Rebased against TOT
>
> Design:
>
> Two patterns have been created:
> - some header files have been broken up into private (lib dir)
> and public (include/openvswitch dir).
> - some header files have been moved from 'lib' to
> 'include/openvswitch'.  All header files in 'include' are considered
> appropriate for third-party inclusion.
>
> Caveats:
>
> - The header files that have been moved to 'include/openvswitch' are the ones
>    that I'm using in my current project.  I'm willing to do the work to move
>    others, but am looking for direction on what should be moved.
> - Little effort has gone into restricting the list of objects that are exported.  All
>    public functions make it into the appropriate .so libraries

I'd recommend enabling symbol versioning from the start. It'll allow you 
to control exactly what is exported and later on, help with backwards 
compatibility which is something that will come up once you're shipping 
shared libraries. See 
https://sourceware.org/binutils/docs/ld/VERSION.html for a brief intro.

> - This is geared towards Debian, although there's nothing Debian-specific in the
>    reworking of header files.
> - In the Debian 'openvswitch-common' package, all command line utilities are now
>    dynamically-linked agains libopenvswitch.so
> - This has only been tested on Linux, although I have it running both against an
>    x86_64 target as well as cross-compiled for MIPS64 (Cavium).
> - I'm a newbie with Debian packaging, which you'll find out if you build this.
>    While the code compiles, links and runs, there are a ton of 'dpkg-shlibdeps'
>    warnings, but I don't know the best practice for declaring symbols.
> - I'm unsure how to version the dynamic libraries.  I guess start with 1.0.0?

Many projects start with 0.0.0 but 1.0.0 is just as well, its not like 
you'll risk running out of numbers there :) But if you're unfamiliar 
with shared library and especially libtool (which is OVS is using) 
versioning, I'd suggest digesting these for starters:
https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

> Going Forward:
>
> - While the code and macros in 'list.h' have pretty good namespace protection,
>    we should probably do some work on 'util.h', and I'm sure there are others.
> - Maybe we should add explicit namespace to the files in 'include'?

Yes, namespacing before going officially public is a very good idea.

	- Panu -





More information about the dev mailing list