[ovs-discuss] porting question

[Mark Haywood]

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.


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

Thanks,
Mark

-------------- next part --------------
24a25
> #ifndef htonll
29a31
> #endif
30a33
> #ifndef ntohll
35a39
> #endif