From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 716D7592E for ; Fri, 25 Jul 2014 03:10:52 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 24 Jul 2014 18:12:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,727,1400050800"; d="scan'208";a="575146607" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by fmsmga002.fm.intel.com with ESMTP; 24 Jul 2014 18:12:20 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Jul 2014 18:12:20 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.204]) by shsmsx102.ccr.corp.intel.com ([169.254.2.120]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 09:12:19 +0800 From: "Wu, Jingjing" To: Antti Kantee , Matthew Hall , "dev@dpdk.org" Thread-Topic: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h Thread-Index: AQHPp5J9VoOAB/x9lky8dbyl42gZ8Juv+jnQ Date: Fri, 25 Jul 2014 01:12:18 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8AB222F@SHSMSX104.ccr.corp.intel.com> References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> In-Reply-To: <53D18EFF.8080804@fixup.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 01:10:52 -0000 Hello, We also notice these conflicts, we just planned to fix it in our new featur= e development. The proposal is like: #ifndef _NETINET_IN_H #ifndef _NETINET_IN_H_ #define IPPROTO_IP 0 ... ...=20 #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 >=20 > 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 IPPR= OTO_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. >=20 > I would namespace the definitions in DPDK, i.e. make them > DPDK_IPPROTO_FOO etc. >=20 > > Thus with all the conflicts it's impossible to use a DPDK IP struct ins= tead 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 t= o > > configure all the IP addresses on your box from a JSON file, which is w= hat 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 i= n my > > opinion very unwisely marked all of the functions as static except for > > cmdline_parse_ipaddr, which only works on the DPDK's proprietary argume= nt > > handling, and not with anything the user might have which is a differen= t > > format. >=20 > 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. >=20 > > 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 av= ailable > > 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 pl= ace > > 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 b= it more > > easily, such as something like this: >=20 > 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"