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

[Matthew Hall <mhall@mhcomputing.net>]

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.
-- 
Sent from my mobile device.

On July 24, 2014 6:12:18 PM PDT, "Wu, Jingjing" <jingjing.wu@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@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"