> > I don't know if it will work right on both Linux and BSD and/or if they also > 100% agree with the libc / glibc values compiled into the > system's .so files. That's the risk that you run if you don't have more > complete support in the DPDK itself for these features.
Looking at linux and freebsd netinet/in.h files - I think it should work. But I suppose we can test it on both freebsd and linux before submitting a patch. > -- > Sent from my mobile device. > > On July 24, 2014 6:12:18 PM PDT, "Wu, Jingjing" <jingjing.wu at intel.com> > wrote: > >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"
