Hello, We also notice these conflicts, we just planned to fix it in our new feature development. The proposal is like:
#ifndef _NETINET_IN_H #ifndef _NETINET_IN_H_ #define IPPROTO_IP 0 ... ... #define IPPROTO_MAX 256 #endif #endif Do you think it is a good idea? > -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Antti Kantee > Sent: Friday, July 25, 2014 6:56 AM > To: Matthew Hall; dev at dpdk.org > Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, > and rte_ip.h > > On 24/07/14 07:59, Matthew Hall wrote: > > Hello, > > > > I ran into some weird symbol conflicts between system netinet/in.h and DPDK > > rte_ip.h. They have a lot of duplicated definitions for stuff like > > IPPROTO_IP > > and so on. This breaks when you want to use inet_pton from arpa/inet.h, > > because it includes netinet/in.h to define struct in_addr. > > I would namespace the definitions in DPDK, i.e. make them > DPDK_IPPROTO_FOO etc. > > > Thus with all the conflicts it's impossible to use a DPDK IP struct instead > > of > > all the system's sockaddr stuff, to store a value from the system copy of > > inet_pton. This would be a common operation if, for example, you want to > > configure all the IP addresses on your box from a JSON file, which is what I > > was doing. > > > > The DPDK kludged around it internally by using a file called > > cmdline_parse_ipaddr.c with private copies of these functions. But it in my > > opinion very unwisely marked all of the functions as static except for > > cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument > > handling, and not with anything the user might have which is a different > > format. > > In my experience from years of fighting with more or less this exact > same problem -- the fight is now thankfully over but the scars remain -- > you either want to expose a complete set of types and provide support > for everything, or you want to expose nothing. Approaches where you use > cute definitions and reuse some host routines is like asking for an > audience with Tyranthraxus when armed with a kitten. It's that doubly > so if you don't have to and do it anyway. > > > So, it would be a big help for users if the macros in librte_net files would > > check if the symbols already existed, or if they had subheader files > > available > > to grab only non conflicting symbols, or if they would make a proper .h and > > factor all the inet_pton and inet_ntop inside the cmdline lib into a place > > where users can access them. It would also be a help if they had a less ugly > > equivalent to struct sockaddr, which let you work with IP addresses a bit > > more > > easily, such as something like this: > > Again, I recommend steering away from any tightrope approaches that > "know" which types are non-conflicting, or pick out half-and-half from > the host and IP stack. "Do, or do not, there is no half-and-half"
