[ovs-dev] Creating a libopenvswitch-dev package

Ben Pfaff blp at ovn.org
Sun Jan 3 02:27:17 UTC 2016


On Thu, Dec 31, 2015 at 03:24:52PM -0800, Ben Warren wrote:
> We use Go as our system programming language, and interact extensively
> with ovs-vswitchd.  Since we’re also keen on the latest things going
> into Openvswitch (currently using conntrack and looking forward to
> NAT), a vanilla Openflow client isn’t very useful - we really need
> something like ovs-ofctl that handles all the extensions.  I’ve been
> playing around with writing a Go wrapper for libopenvswitch.so and
> takes advantage of all the wonderful parsing and serdes functions that
> the OVS team has written.  I have it working well, but there’s a lot
> of hackery around getting header files in the right places.  We’re
> also a Debian shop, and I’d really like to be able to distribute the
> shared libraries and header files in the vein of libfoo-dev packages.
> 
> I’m happy to do the leg work to make this happen, but would like some
> guidance on how the files should be organized.  I see that there are
> already rules for assembling the “include/openvswitch” and
> “include/openflow” headers, but not the core ones in “lib” that I
> need.  I found some discussion on the mailing list from when the
> “—enable-shared” configure option was added, mainly about API
> versioning etc, so it seems that mine isn’t a new idea, and there are
> probably others that would benefit.

Most of the Open vSwitch libraries aren't well organized for use by
outside software.  We're probably overdue to fix that, but so far little
effort has been put into it.

There's a couple of approaches we could take here.  One is to start
working toward making the most important OVS libraries more friendly for
use by outside software.  That would probably involve moving headers
from lib/ to include/openvswitch while considering whether their names
and interfaces were appropriate.  Another approach would be to just
semi-officially sanction some nasty hacks and push off doing it
"correctly" into the indefinite future.  Though I'd prefer the first
approach, the second might be OK if it doesn't prevent doing it
correctly in future versions.

What APIs in particular are you thinking about?



More information about the dev mailing list