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 5A3EA592E for ; Fri, 25 Jul 2014 01:02:33 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id D59C380C764; Thu, 24 Jul 2014 16:03:27 -0700 (PDT) Date: Thu, 24 Jul 2014 16:03:27 -0700 From: Matthew Hall To: Antti Kantee Message-ID: <20140724230327.GA26512@mhcomputing.net> References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D18EFF.8080804@fixup.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" 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: Thu, 24 Jul 2014 23:02:33 -0000 On Thu, Jul 24, 2014 at 10:55:59PM +0000, Antti Kantee wrote: > 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. I don't have a problem with this approach. Implementing it would require the DPDK to create user accessible functions for creating MAC addresses, IPs, CIDRs, and TCP / UDP port numbers. Many of the things required are hiding inside of *cmdline* code where it's impossible for anybody to access them. Matthew.