[ovs-discuss] porting question

Mark Haywood mark.haywood at oracle.com
Mon Apr 28 23:01:02 UTC 2014


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?


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

Thanks,
Mark





More information about the discuss mailing list