[ovs-discuss] porting question

Mark Haywood mark.haywood at oracle.com
Thu May 1 01:26:55 UTC 2014


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.


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

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.

Thanks,
Mark




More information about the discuss mailing list