[ovs-dev] Creating a libopenvswitch-dev package

[Ben Warren]

> On Jan 2, 2016, at 6:27 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> 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.
> 
I’ll start down the path of doing the right thing, and will only veer off into hack land if absolutely necessary.  Moving files around and making sure things compile is easy - refactoring interfaces will require a lot more context and knowledge of the code base.  Another big caveat is that I’m only able to build and test the parts that we use.  Hopefully others can make up the difference.
> What APIs in particular are you thinking about?
I’ll get the biggest bang out of programmatically implementing ‘ovs-ofctl’.  The first order of business is to parse flow information using ‘parse_ofp_flow_mod_str()’ and ‘ofputil_encode_flow_mod()’, then send it on the wire using a socket that my code manages.  I can see how these might be simplified when thinking about external-facing interfaces into a single function that takes a string a returns something close to a raw buffer, but understand that it will take time and iteration to get this right.

cheers,
Ben