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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
