From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Hall Subject: Re: [PATCH] llib/ibrte_net: workaround to avoid macro conflict Date: Wed, 08 Oct 2014 22:37:28 -0700 Message-ID: <5FCF04AC-4DFB-47DE-B2E9-514FF8CC2F76@mhcomputing.net> 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Wu, Jingjing" , Neil Horman Return-path: In-Reply-To: <9BB6961774997848B5B42BEC655768F8B04B34-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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 e= very other important socket function which depends upon in.h or depends u= pon code depending upon in.h. Clearly this doesn't represent a sustainabl= e 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 onl= y one who ran into this issue either. Matthew. --=20 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-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org]=20 >Sent: Tuesday, September 30, 2014 9:10 PM >To: Wu, Jingjing >Cc: dev-VfR2kkLFssw@public.gmane.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=20 >> time, there will be conflict error. >>=20 >> This patch uses the way "#ifndef #endif" to avoid the conflict.=20 >>=20 >> Signed-off-by: Jingjing Wu >> --- >> lib/librte_net/rte_ip.h | 5 +++++ >> 1 file changed, 5 insertions(+) >>=20 >> diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h index=20 >> e3f65c1..2bcb479 100644 >> --- a/lib/librte_net/rte_ip.h >> +++ b/lib/librte_net/rte_ip.h >> @@ -116,6 +116,8 @@ struct ipv4_hdr { >> =20 >> #define IPV4_HDR_OFFSET_UNITS 8 >> =20 >> +#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 */ >> =20 >> +#endif /*_NETINET_IN_H_*/ >> +#endif /*_NETINET_IN_H*/ >> + >> /* >> * IPv4 address types >> */ >> -- >> 1.8.1.4 >>=20 >>=20 >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