On 03/03/2016 08:20 PM, b...@skyportsystems.com wrote:
From: Ben Warren <b...@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 -
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
