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? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
