[ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
Ben Pfaff
blp at ovn.org
Wed Jun 8 20:30:34 UTC 2016
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.
Acked-by: Ben Pfaff <blp at ovn.org>
More information about the dev
mailing list