From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: DPDK namespace Date: Fri, 08 Apr 2016 00:01:14 +0200 Message-ID: <3669443.CoLShL9pDx@xps13> References: <1610488.T03Kyi0Reo@xps13> <5911950.ZPQvAWoePl@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit To: dev@dpdk.org Return-path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 31FD52BA8 for ; Fri, 8 Apr 2016 00:01:17 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id 191so101206wmq.0 for ; Thu, 07 Apr 2016 15:01:17 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id o128sm9423wmb.19.2016.04.07.15.01.15 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 15:01:16 -0700 (PDT) In-Reply-To: <5911950.ZPQvAWoePl@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-04-07 11:18, Thomas Monjalon: > 2016-04-05 15:56, Thomas Monjalon: > > The goal of this email is to get some feedback on how important it is > > to fix the DPDK namespace. > > Everybody agree every symbols must be prefixed. Checking and fixing the > namespace consistency will be in the roadmap. > > It seems most of you agree renaming would be a nice improvement but not > so important. The main benefits are: - consistency with the name of the project - avoid a namespace clash with another library using "rte" prefix (the dpdk word is kind of reserved now) > The main drawback is the induced backporting pain, even if we have > some scripts to convert the patches to the old namespace. > Note: the backports can be in DPDK itself or in the applications. > > > If there is enough agreement that we should do something, I suggest to > > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" > > during some time. > > We could start using the new prefix for the new APIs (example: crypto) > > or when there is a significant API break (example: mempool). > > The slow change has been clearly rejected in favor of a complete change > in one patch. > The timing was also discussed as it could impact the pending patches. > So it would be done at the end or the beginning of a release. > Marc suggests to do it for 16.04 as the numbering scheme has changed. > > There is no strong conclusion at this point because we need to decide > wether the renaming deserves to be done or never. > I suggest to take the inputs from the technical board. The technical board has agreed that the renaming cannot happen in 16.04. The pro/cons balance need to be discussed more. The plan is to keep the discussion open during the next 2 weeks and take a decision based on the discussion outcome.