Re: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h

["Wu, Jingjing" <jingjing.wu@intel.com>]

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@dpdk.org] On Behalf Of Antti Kantee
> Sent: Friday, July 25, 2014 6:56 AM
> To: Matthew Hall; dev@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"