From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 3C0141B122 for ; Wed, 24 Oct 2018 18:39:13 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 09:39:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,421,1534834800"; d="scan'208";a="102946150" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by orsmga002.jf.intel.com with SMTP; 24 Oct 2018 09:39:10 -0700 Received: by (sSMTP sendmail emulation); Wed, 24 Oct 2018 17:39:10 +0100 Date: Wed, 24 Oct 2018 17:39:09 +0100 From: Bruce Richardson To: Olivier Matz Cc: dev@dpdk.org Message-ID: <20181024163909.GA12444@bricha3-MOBL.ger.corp.intel.com> References: <20181024081833.21432-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024081833.21432-1-olivier.matz@6wind.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [RFC 00/14] prefix network structures 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: Wed, 24 Oct 2018 16:39:14 -0000 On Wed, Oct 24, 2018 at 10:18:19AM +0200, Olivier Matz wrote: > This RFC targets 19.02. > > The rte_net headers conflict with the libc headers, because > some definitions are duplicated, sometimes with few differences. > This was discussed in [1], and more recently at the techboard. > > Before sending the deprecation notice (target for this is 18.11), > here is a draft that can be discussed. > > This RFC adds the rte_ (or RTE_) prefix to all structures, functions > and defines in rte_net library. This is a big changeset, that will > break the API of many functions, but not the ABI. > > One question I'm asking is how can we manage the transition. > Initially, I hoped it was possible to have a compat layer during > one release (supporting both prefixed and unprefixed names), but > now that the patch is done, it seems the impact is too big, and > impacts too many libraries. > > Few examples: > - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *) > - many rte_flow structures use the rte_ prefixed net structures > - the mac field of virtio_net structure is rte_ether_addr > - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *) > ... > > Therefore, it is clear that doing this would break the compilation > of many external applications. > Can you clarify a bit as to why we can't keep around compatibility versions of the headers, alongside the new versions? I'm not following the logic above. Can we not introduce completely new headers with the replacements while leaving the old ones intact? /Bruce