From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: DPDK namespace Date: Thu, 7 Apr 2016 12:33:14 +0300 Message-ID: <5706295A.3000406@redhat.com> References: <1610488.T03Kyi0Reo@xps13> <5911950.ZPQvAWoePl@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: techboard@dpdk.org To: Thomas Monjalon , dev@dpdk.org Return-path: 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" On 04/07/2016 12:18 PM, Thomas Monjalon wrote: > Thank you everyone for the feedbacks. > > 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 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. Just noting that it cannot be done in 16.04 because the ABI policy requires a deprecation cycle of at least one major release for every breakage. And we're discussing a total 100% breakage of everything here, even if its just a simple rename. - Panu - > 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. > > Do not hesitate to comment. Thanks >