From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186]) by dpdk.org (Postfix) with ESMTP id F1C62592E for ; Fri, 25 Jul 2014 06:54:49 +0200 (CEST) Received: from android-fb5fc4f6ed62fb42 (172-3-139-73.lightspeed.sntcca.sbcglobal.net [172.3.139.73]) by mail.mhcomputing.net (Postfix) with ESMTPSA id 9ABDB80BDB3; Thu, 24 Jul 2014 21:55:44 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <9BB6961774997848B5B42BEC655768F8AB222F@SHSMSX104.ccr.corp.intel.com> References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> <9BB6961774997848B5B42BEC655768F8AB222F@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Matthew Hall Date: Thu, 24 Jul 2014 21:56:12 -0700 To: "Wu, Jingjing" , Antti Kantee , "dev@dpdk.org" Message-ID: Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:54:50 -0000 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" 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"