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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
