From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:organization:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ymv2bCzbSQssE6sWGnGa4zZPuxzWSuM5IkdifW2XdmQ=; b=10B8fyUlVyDdGfkvycoThFFaOqx6LxzmIBBSnsosAJ2dcT4mtz6vckXGwPHv+/bm99 O/w6M5W1zqySlqF714TcxJa2gCGK8jjDzPJZqGsH8TyezWUQpbrfEKue8tgCU6sm/uXC 6QWdhy9NNOKgvoPHCCHzkMcxa2dO8JfZkX0n2CQcg3v5fgL94WoxPHeuj510CLuBqvBW gI//OmBJAgRX/yiWsqRUoLgS/bFV8+PYp98GqsotM5wfJEduTITg4pbvqMrjVbX9RXkQ jcYczgSEqrX56UDhgupQAuXymkw1+R0h2lmfeJ8Ws3I5jGsoyKYSWOrFph45r4dmf0ms 4nAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=Ymv2bCzbSQssE6sWGnGa4zZPuxzWSuM5IkdifW2XdmQ=; b=BcsqZngu/WdxIFCQmdk05np389dCaGRUJQgicHv9V3eM+XQxrJ3WVM24x3Hkd0t6Ei zF4JOEfkGULsuIgH8E2D2JGvvLnW+MG51skwZxYnaZ85OxyBvNWQ6sYOxx4gYF6HqQkW D8jjtbR/F9OG4owcLgag5+Jc7AmHkxWm+f818iAevu2i+VLWjcX5rA0qN3RXu06iDWa2 jKymL0Ooqtd2aUOnrASFsTgN0QzELB7rCnd7YFAMO/hnVxw/dWy3VGBmqWhs33kqkGBA rX0+I7zoZuCB/9BRwJDma1UTWl+p4ZURGB5KCPTN8Euh4TmSTenUI/cmyReXRh8eFLw9 0O/A== X-Gm-Message-State: AD7BkJKQsbaoraClSPSHXHDh6X+wZ+Uh25zjOMEYgmTrHEbUIVUqXxLHSPrBMEaG1t1B47JR X-Received: by 10.28.153.65 with SMTP id b62mr26355wme.36.1460066476948; Thu, 07 Apr 2016 15:01:16 -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) From: Thomas Monjalon To: dev@dpdk.org Date: Fri, 08 Apr 2016 00:01:14 +0200 Message-ID: <3669443.CoLShL9pDx@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5911950.ZPQvAWoePl@xps13> References: <1610488.T03Kyi0Reo@xps13> <5911950.ZPQvAWoePl@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] DPDK namespace 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, 07 Apr 2016 22:01:17 -0000 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.