[ovs-discuss] porting question

Ben Pfaff blp at nicira.com
Tue Apr 29 19:58:08 UTC 2014


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.

> >>>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.



More information about the discuss mailing list