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 A0AFD68CB for ; Thu, 9 Oct 2014 07:30:14 +0200 (CEST) Received: from 1-25-220-21.pools.spcsdns.net (unknown [66.87.119.1]) by mail.mhcomputing.net (Postfix) with ESMTPSA id 20CB480C3D9; Wed, 8 Oct 2014 22:36:49 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <9BB6961774997848B5B42BEC655768F8B04B34@SHSMSX104.ccr.corp.intel.com> References: <1412045348-18543-1-git-send-email-jingjing.wu@intel.com> <20140930130950.GF2193@hmsreliant.think-freely.org> <9BB6961774997848B5B42BEC655768F8B04B34@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Matthew Hall Date: Wed, 08 Oct 2014 22:37:28 -0700 To: "Wu, Jingjing" , Neil Horman Message-ID: <5FCF04AC-4DFB-47DE-B2E9-514FF8CC2F76@mhcomputing.net> Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] llib/ibrte_net: workaround to avoid macro conflict 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, 09 Oct 2014 05:30:14 -0000 If the DPDK wants to conflict with all those system headers it means they also have to provide working replacement for inet_pton, inet_ntop, and every other important socket function which depends upon in.h or depends upon code depending upon in.h. Clearly this doesn't represent a sustainable path for software development... I had to reimplement a number of these in my app to get around the header conflict and I'm sure I'm not the only one who ran into this issue either. Matthew. -- Sent from my mobile device. On October 8, 2014 10:20:31 PM PDT, "Wu, Jingjing" wrote: >Hi, Neil > >To have rte_ip.h include netinet/in.h directly is also a choice. > >But netinet/in.h contains a lot of extra stuff, and these may be >useless some DPDK applications, such as classification. >rte_ip.h provides a more simplify way for the IP protocol layer. > >-----Original Message----- >From: Neil Horman [mailto:nhorman@tuxdriver.com] >Sent: Tuesday, September 30, 2014 9:10 PM >To: Wu, Jingjing >Cc: dev@dpdk.org >Subject: Re: [dpdk-dev] [PATCH] llib/ibrte_net: workaround to avoid >macro conflict > >On Tue, Sep 30, 2014 at 10:49:08AM +0800, Jingjing Wu wrote: >> Macros such as IPPROTO_TCP, IPPROTO_UDP are already defined in >. >> If user's application includes and rte_ip.h at the >same >> time, there will be conflict error. >> >> This patch uses the way "#ifndef #endif" to avoid the conflict. >> >> Signed-off-by: Jingjing Wu >> --- >> lib/librte_net/rte_ip.h | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h index >> e3f65c1..2bcb479 100644 >> --- a/lib/librte_net/rte_ip.h >> +++ b/lib/librte_net/rte_ip.h >> @@ -116,6 +116,8 @@ struct ipv4_hdr { >> >> #define IPV4_HDR_OFFSET_UNITS 8 >> >> +#ifndef _NETINET_IN_H >> +#ifndef _NETINET_IN_H_ >> /* IPv4 protocols */ >> #define IPPROTO_IP 0 /**< dummy for IP */ >> #define IPPROTO_HOPOPTS 0 /**< IP6 hop-by-hop options */ >> @@ -227,6 +229,9 @@ struct ipv4_hdr { >> #define IPPROTO_RAW 255 /**< raw IP packet */ >> #define IPPROTO_MAX 256 /**< maximum protocol number */ >> >> +#endif /*_NETINET_IN_H_*/ >> +#endif /*_NETINET_IN_H*/ >> + >> /* >> * IPv4 address types >> */ >> -- >> 1.8.1.4 >> >> >Why define them at all? Why not just have rte_ip.h include >netinet/in.h directly? Its a standard include file in a standard >location for both bsd and linux IIRC. >Neil