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

[Antti Kantee <pooka@fixup.fi>]

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"