From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Niraj Sharma (nirajsha)" Subject: Re: symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h Date: Thu, 24 Jul 2014 15:43:08 +0000 Message-ID: References: <20140724075918.GA21277@mhcomputing.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: Matthew Hall , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <20140724075918.GA21277-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org> Content-Language: en-US Content-ID: <91E382E4810AA84E8A3919BDF8EBE787-WwaMAgPkaIIluPl5bxqUMw@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" I also noticed this problem. It is a serious one. I would like it solved. -- Niraj Sharma Principal Eng. Cisco System, Inc. On 7/24/14 12:59 AM, "Matthew Hall" wrote: >Hello, > >I ran into some weird symbol conflicts between system netinet/in.h and >DPDK=20 >rte_ip.h. They have a lot of duplicated definitions for stuff like >IPPROTO_IP=20 >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. > >Thus with all the conflicts it's impossible to use a DPDK IP struct >instead of=20 >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=20 >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=20 >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. > >So, it would be a big help for users if the macros in librte_net files >would=20 >check if the symbols already existed, or if they had subheader files >available=20 >to grab only non conflicting symbols, or if they would make a proper .h >and=20 >factor all the inet_pton and inet_ntop inside the cmdline lib into a >place=20 >where users can access them. It would also be a help if they had a less >ugly=20 >equivalent to struct sockaddr, which let you work with IP addresses a bit >more=20 >easily, such as something like this: > >struct ip4_addr { > uint32_t addr; >}; > >typedef struct ip4_addr ip4_addr; > >struct ip6_addr { > uint8_t addr[16]; >}; > >typedef struct ip6_addr ip6_addr; > >struct ip_addr { > uint8_t family; > uint8_t prefix; > union { > struct ip4_addr ipv4; > struct ip6_addr ipv6; > }; >}; > >I had to create a bunch of duplicate code to handle it in my project, >since=20 >the DPDK marked its copies of all these functions as "secret" and didn't >make=20 >a .h for them. If any of it is useful I am happy to donate it, although I >don't think I've got quite enough experience with this specifc part of >the=20 >DPDK to code it up all by myself. > >Thanks, >Matthew.