From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by dpdk.org (Postfix) with ESMTP id 5D0F8592E for ; Fri, 25 Jul 2014 16:38:35 +0200 (CEST) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTPS id 11E5630944F; Fri, 25 Jul 2014 17:40:03 +0300 (EEST) Message-ID: <53D26C42.3060907@fixup.fi> Date: Fri, 25 Jul 2014 14:40:02 +0000 From: Antti Kantee MIME-Version: 1.0 To: Thomas Monjalon , dev@dpdk.org References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> <1432797.FfhxlLyX1P@xps13> In-Reply-To: <1432797.FfhxlLyX1P@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 14:38:35 -0000 On 25/07/14 10:43, Thomas Monjalon wrote: >> On 24/07/14 07:59, Matthew Hall wrote: >>> 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. > [...] >> 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" > > The general problem here is that DPDK is conflicting with libc. > So the obvious question would be: "why DPDK needs to redefine libc stuff"? > I don't see any obvious answer since bare metal is planned to be removed. > (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) One reason is if you want DPDK to be a portable network programming environment. Especially in that case you do not want definitions based on hackish assumptions of some particular version of some particular host implementation. However, I'm not trying to argue if DPDK should or shouldn't be that, just that you should either dramatically improve the current implementation or nuke it.