From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 898351B052 for ; Tue, 16 Jan 2018 14:04:18 +0100 (CET) Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ebQuY-0008Tm-MF; Tue, 16 Jan 2018 14:04:19 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 16 Jan 2018 14:04:13 +0100 Date: Tue, 16 Jan 2018 14:04:13 +0100 From: Olivier Matz To: Adrien Mazarguil Cc: dev@dpdk.org, Bruce Richardson Message-ID: <20180116130413.q4alhcwvdbgpo3gc@platinum> References: <20171221122458.811-1-adrien.mazarguil@6wind.com> <20171221122458.811-7-adrien.mazarguil@6wind.com> <20171222133420.64zut4nbwcuft3fs@platinum> <20171222142527.GQ5377@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171222142527.GQ5377@6wind.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v1 6/6] net: fix rte_ether conflicts with libc X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 13:04:18 -0000 Hi Adrien, On Fri, Dec 22, 2017 at 03:25:27PM +0100, Adrien Mazarguil wrote: > On Fri, Dec 22, 2017 at 02:34:21PM +0100, Olivier MATZ wrote: > > On Thu, Dec 21, 2017 at 02:00:06PM +0100, Adrien Mazarguil wrote: ... > > > +#if defined(__FreeBSD__) > > > +#define addr_bytes octet > > > +#else > > > +#define addr_bytes ether_addr_octet > > > +#endif > > > + > > > #define ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */ > > > #define ETHER_GROUP_ADDR 0x01 /**< Multicast or broadcast Eth. address. */ > > > > This kind of #define looks a bit dangerous to me: it can trigger > > strange bugs because it will replace all occurences of addr_bytes > > after this header is included. > > Understandable, I checked before settling on this macro though, there's no > other usage of addr_bytes inside DPDK. > > As for applications, there's no way to be completely sure. If we consider > they have to explicitly include rte_ether.h to get this definition, there > are chances addr_bytes is exclusively used with MAC addresses. > > This change results in an API change (addr_bytes now documented as a > reserved macro) but has no ABI impact. I think it's a rather harmless > workaround pending your next suggestion: > > > Wouldn't it be a good opportunity to think about adding the rte_ prefix > > to all variables/functions of rte_ether.h? > > That would be ideal, however since almost all definitions in librte_net > (rte_ip.h, rte_udp.h etc.) also lack this prefix and can still technically > trigger conflicts with outside definitions (I'm aware work was done to avoid > that, but it doesn't change the fact they're not in the official DPDK > namespace), a massive API change would be needed for consistency. > > Such a change is unlikely to be accepted for 18.02 in any case, therefore if > the proposed workaround is deemed too risky, I offer to remove this patch > from the series. What do you suggest? I think the only good long term solution is to have a proper namespace for all rte_net structures and definitions. If there is no blocking issue requiring this patch now, we can consider the following: - 18.02: announce an api change for 18.05 - 18.05: - add new net structures and definitions with rte_ prefix - mark the old ones as deprecated - removes the structures or definitions that conflicts with system headers - 18.08: remove the old structures and definitions