On 8 June 2016 at 13:49, Daniele Di Proietto <diproiet...@vmware.com> wrote:
>
>
>
>
>
> On 08/06/2016 13:30, "Ben Pfaff" <b...@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 <b...@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
