[ovs-discuss] porting question

Ben Pfaff blp at nicira.com
Thu May 1 14:12:48 UTC 2014


On Wed, Apr 30, 2014 at 09:26:55PM -0400, Mark Haywood wrote:
> On 4/29/14 3:58 PM, Ben Pfaff wrote:
> >On Tue, Apr 29, 2014 at 03:51:45PM -0400, Mark Haywood wrote:
> >>On 4/28/14 11:53 PM, Ben Pfaff wrote:
> >>>On Mon, Apr 28, 2014 at 07:01:02PM -0400, Mark Haywood wrote:
> >>>>On 4/28/14, 6:36 PM, Ben Pfaff wrote:
> >>>>>On Mon, Apr 28, 2014 at 03:06:50PM -0400, Mark Haywood wrote:
> >>>>>>I'm investigating porting the OVS code (well, at least the userspace
> >>>>>>portions) to Solaris. On my first stab, I immediately ran into a
> >>>>>>couple of issues,
> >>>>>>
> >>>>>>1 - lib/byte-order.h defines htonll and ntohll inline functions
> >>>>>>which are already defined as macros on Solaris resulting in compile
> >>>>>>time errors.
> >>>>>>
> >>>>>>2 - lib/flow.c references a structure ip6_ext that is defined in OVS
> >>>>>>in netinet/ip6.h. However, Solaris has its own version of
> >>>>>>netinet/ip6.h which supersedes the one
> >>>>>>      included by OVS.
> >>>>>>
> >>>>>>I can certainly think of ways of working around these issues.
> >>>>>>However, it was my hope that, once I ported to Solaris, the changes
> >>>>>>could be incorporated
> >>>>>>back into the base source. Given that the OVS source has already
> >>>>>>been ported to FreeBSD and NetBSD, I assume issues like this have
> >>>>>>been encountered.
> >>>>>>Are there any general rules on how OS portability issues should be resolved?
> >>>>>Yes.
> >>>>Thanks for the response Ben.
> >>>>
> >>>>
> >>>>>For 1, submit a patch to check for htonll and ntohll macros and skip
> >>>>>defining them if they exist.
> >>>>To make sure I understand, modify the header file to conditionally
> >>>>compile the inline copies of the functions and submit that (along
> >>>>with other changes I'd imagine) back - after proper review?
> >>>Yes.
> >>>
> >>>(You need not queue up multiple changes to submit together.  In fact we
> >>>prefer small patches that make sense individually.)
> >>OK. I've attached a patch file for lib/byte-order.h. Is there a more
> >>official process for submitting a patch? Sorry, this is new
> >>territory for me.
> >Yes, the file CONTRIBUTING at the top of the tree explains how to
> >submit a patch.
> 
> 
> I don't see a CONTRIBUTING file. So, I assume you mean
> SubmittingPatches. I'll digest it and send a patch for the change to
> lib/byte-order.h.

CONTRIBUTING was previously named SubmittingPatches.  (Please make sure
that you base your work on the newest ("master") version of Open
vSwitch.)

> >>>>>2 doesn't make sense because OVS doesn't define such a struct outside
> >>>>>of "sparse"-specific or Windows-specific headers.  You shouldn't be
> >>>>>using those headers, and I can't imagine how the build system would
> >>>>>have pulled them in automatically.
> >>>>I agree. It didn't make sense to me either. I saw that that
> >>>>netinet/ip6.h was only supposed to be built with sparse (not that I
> >>>>know what that is, but I'm sure I'm not supposed to be building it).
> >>>>
> >>>>However, I simply followed the INSTALL directions.
> >>>>
> >>>>1 - ./boot.sh
> >>>>2 - ./configure
> >>>>3 - gmake
> >>>>
> >>>>As part of this build, lib/flow.c is being built. And as I said,
> >>>>parse_ipv6() includes the following line:
> >>>>
> >>>>const struct ip6_ext *ext_hdr = packet->data;
> >>>>
> >>>>So, am I supposed to be doing something to prevent lib/flow.c from
> >>>>being built?
> >>>No.  You should figure out why the build is somehow including
> >>>include/sparse/netinet/ip6.h.  To begin with, what's the full compiler
> >>>invocation during the "make" process?
> >>
> >>You're right. It was nonsense on my part. I assumed that it was
> >>supposed to be included because it was the only place in the source
> >>where the ip6_ext struct was being defined. I think lib/flow.c
> >>expects the ip6_ext struct to be defined in ip6.h. Solaris does not
> >>define it there. I'll see if I can have the Solaris header file
> >>updated to include the structure.
> >OK.  We'd also take a patch to #include whatever header is needed on
> >Solaris; that would be the usual fix.
> 
> Unfortunately, there is no Solaris header that includes the
> structure. And it seems reasonable that the ip6_ext structure be
> included in the netinet/ip6.h header. So, I'll pursue that.

OK.

It would also not be very difficult to make the build process detect
whether ip6_ext is defined in the headers and, if not, define it
ourselves.

> So, my next problem is that my build of lib fails when trying to
> build netdev-bsd.c. It seems to me that since I'm really only
> interested in building the userspace-only mode of Open vSwitch, that
> I probably don't want to build netdev-bsd.c? Is there a supported
> build process for this? When I read INSTALL.userspace, it said that
> should follow the procudure defined in INSTALL. But that is the
> procedure I followed and it is trying to build netdev-bsd.c.

The "right thing" to do here is to port netdev-bsd so that it builds on
Solaris.  But you can get farther in the build process if you just
delete mention of netdev-bsd.c from lib/automake.mk, skipping that
build.



More information about the discuss mailing list