Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
On 27/09/2016 15:19, "Joe Stringer"wrote: >On 8 June 2016 at 13:49, Daniele Di Proietto wrote: >> >> >> >> >> >> On 08/06/2016 13:30, "Ben Pfaff" 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 >> >> 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 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
On 8 June 2016 at 13:49, Daniele Di Proiettowrote: > > > > > > On 08/06/2016 13:30, "Ben Pfaff" 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 > > 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
Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
On 08/06/2016 13:30, "Ben Pfaff"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 Thanks for the review and testing, I pushed this to master ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
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___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
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? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
On 1 June 2016 at 19:23, Daniele Di Proiettowrote: > 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. > > sample output from sparse: > > /usr/include/linux/in.h:29:9: warning: preprocessor token IPPROTO_IP > redefined > ../include/sparse/netinet/in.h:60:9: this was the original definition > /usr/include/linux/in.h:31:9: warning: preprocessor token IPPROTO_ICMP > redefined > ../include/sparse/netinet/in.h:63:9: this was the original definition > [...] > /usr/include/linux/in.h:28:3: error: bad enum definition > /usr/include/linux/in.h:28:3: error: Expected } at end of specifier > /usr/include/linux/in.h:28:3: error: got 0 > /usr/include/linux/in.h:84:16: error: redefinition of struct in_addr > > Signed-off-by: Daniele Di Proietto I was noticing these issues too, thanks for fixing them. Tested-by: Joe Stringer ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h
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. sample output from sparse: /usr/include/linux/in.h:29:9: warning: preprocessor token IPPROTO_IP redefined ../include/sparse/netinet/in.h:60:9: this was the original definition /usr/include/linux/in.h:31:9: warning: preprocessor token IPPROTO_ICMP redefined ../include/sparse/netinet/in.h:63:9: this was the original definition [...] /usr/include/linux/in.h:28:3: error: bad enum definition /usr/include/linux/in.h:28:3: error: Expected } at end of specifier /usr/include/linux/in.h:28:3: error: got 0 /usr/include/linux/in.h:84:16: error: redefinition of struct in_addr Signed-off-by: Daniele Di Proietto--- include/sparse/netinet/in.h | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/include/sparse/netinet/in.h b/include/sparse/netinet/in.h index 78e5981..8a5b887 100644 --- a/include/sparse/netinet/in.h +++ b/include/sparse/netinet/in.h @@ -18,8 +18,8 @@ #error "Use this header only with sparse. It is not a correct implementation." #endif -#ifndef __NETINET_IN_SPARSE -#define __NETINET_IN_SPARSE 1 +#ifndef _NETINET_IN_H +#define _NETINET_IN_H 1 #include "openvswitch/types.h" #include @@ -77,25 +77,25 @@ struct sockaddr_in6 { #define IPPORT_FTP 21 /* All the IP options documented in Linux ip(7). */ -#define IP_ADD_MEMBERSHIP 0 -#define IP_DROP_MEMBERSHIP 1 -#define IP_HDRINCL 2 -#define IP_MTU 3 -#define IP_MTU_DISCOVER 4 -#define IP_MULTICAST_IF 5 -#define IP_MULTICAST_LOOP 6 -#define IP_MULTICAST_TTL 7 -#define IP_NODEFRAG 8 -#define IP_OPTIONS 9 -#define IP_PKTINFO 10 +#define IP_ADD_MEMBERSHIP 35 +#define IP_DROP_MEMBERSHIP 36 +#define IP_HDRINCL 3 +#define IP_MTU 14 +#define IP_MTU_DISCOVER 10 +#define IP_MULTICAST_IF 32 +#define IP_MULTICAST_LOOP 34 +#define IP_MULTICAST_TTL 33 +#define IP_NODEFRAG 22 +#define IP_OPTIONS 4 +#define IP_PKTINFO 8 #define IP_RECVERR 11 -#define IP_RECVOPTS 12 +#define IP_RECVOPTS 6 #define IP_RECVTOS 13 -#define IP_RECVTTL 14 -#define IP_RETOPTS 15 -#define IP_ROUTER_ALERT 16 -#define IP_TOS 17 -#define IP_TTL 18 +#define IP_RECVTTL 12 +#define IP_RETOPTS 7 +#define IP_ROUTER_ALERT 5 +#define IP_TOS 1 +#define IP_TTL 2 #define INADDR_ANY 0x #define INADDR_BROADCAST0x @@ -146,4 +146,4 @@ int inet_aton (const char *, struct in_addr *); const char *inet_ntop(int, const void *, char *, socklen_t); int inet_pton(int, const char *, void *); -#endif /* sparse */ +#endif /* */ -- 2.8.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev