[ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h

[Daniele Di Proietto]

On 27/09/2016 15:19, "Joe Stringer" <joe at ovn.org> wrote:

>On 8 June 2016 at 13:49, Daniele Di Proietto <diproiettod at vmware.com> wrote:
>>
>>
>>
>>
>>
>> On 08/06/2016 13:30, "Ben Pfaff" <blp at ovn.org> wrote:
>>
>>>On Wed, Jun 08, 2016 at 01:07:32PM -0700, Ben Pfaff wrote:
>>>> On Wed, Jun 01, 2016 at 07:23:29PM -0700, Daniele Di Proietto wrote:
>>>> > linux/in.h (from linux uapi headers) carries many of the same
>>>> > definitions as netinet/in.h (from glibc).
>>>> >
>>>> > If linux/in.h is included after netinet/in.h, conflicts are avoided in
>>>> > two ways:
>>>> >
>>>> > 1) linux/libc-compat.h (included by linux/in.h) detects the include
>>>> >    guard of netinet/in.h and defines some macros (e.g.
>>>> >    __UAPI_DEF_IN_IPPROTO) to 0.  linux/in.h avoids exporting the same
>>>> >    enums if those macros are 0.
>>>> >
>>>> > 2) The two files are allowed to redefine the same macros as long as the
>>>> >    values are the same.
>>>> >
>>>> > Our include/sparse/netinet/in.h creates problems, because:
>>>> >
>>>> > 1) It uses a custom include guard
>>>> > 2) It uses dummy values for some macros.
>>>> >
>>>> > This commit changes include/sparse/netinet/in.h to use the same include
>>>> > guard as glibc netinet/in.h, and to use the same values for some macros.
>>>> >
>>>> > I think this problem is present with linux headers after
>>>> > a263653ed798("netfilter: don't pull include/linux/netfilter.h from netns
>>>> > headers") which cause our lib/netlink-conntrack.c to include linux/in.h
>>>> > after netinet/in.h.
>>>>
>>>> The change to the macros seems fine.
>>>>
>>>> The change to the include guard concerns me though.  If other
>>>> definitions of e.g. htons() are used, then how will those have the
>>>> correct types for sparse checking?
>>>
>>>After talking to Daniele I understand better.  The reason to use glibc's
>>>header guard is that the Linux headers check for glibc's header guard
>>>and behave differently if it is present, and we want that same behavior
>>>when our "sparse"-compatible header is used.  Now that I understand, I
>>>support the change.
>>
>> Yeah, it's quite intricated
>>
>> I'm not sure our sparse headers cover all corner cases of glibc+linux headers,
>> but for now the build appears to work.
>>
>>>
>>>Acked-by: Ben Pfaff <blp at ovn.org>
>>
>> Thanks for the review and testing, I pushed this to master
>
>I'd like to propose cherry-picking this to OVS-2.5 before the next
>v2.5 release, to fix the userspace build using sparse with newer
>kernels.

Good idea, I run make distcheck to make sure that this doesn't break anything and I backported it to branch-2.5

Thanks,

Daniele