From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id E51CA2BFE for ; Wed, 6 Apr 2016 07:25:24 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 05 Apr 2016 22:25:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,447,1455004800"; d="scan'208";a="939243074" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.191]) by fmsmga001.fm.intel.com with ESMTP; 05 Apr 2016 22:25:17 -0700 Date: Wed, 6 Apr 2016 13:26:56 +0800 From: Yuanhan Liu To: Arnon Warshavsky Cc: "Trahe, Fiona" , Thomas Monjalon , "dev@dpdk.org" Message-ID: <20160406052656.GT3080@yliu-dev.sh.intel.com> References: <1610488.T03Kyi0Reo@xps13> <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 06 Apr 2016 05:25:25 -0000 On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote: > On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona wrote: > > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > Sent: Tuesday, April 05, 2016 2:57 PM > > > To: dev@dpdk.org > > > Subject: [dpdk-dev] DPDK namespace > > > > > > DPDK is going to be more popular in Linux distributions. > > > It means people will have some DPDK files in their /usr/include and some > > DPDK > > > libraries on their system. > > > > > > Let's imagine someone trying to compile an application which needs > > > rte_ethdev.h. He has to figure out that this "rte header" is provided by > > the DPDK. > > > Hopefully it will be explained on StackOverflow that RTE stands for DPDK. > > > Then someone else will try to run a binary without having installed the > > DPDK > > > libraries. The linker will require libethdev.so (no prefix here). > > > StackOverflow will probably have another good answer (among wrong ones): > > > "Hey Sherlock Holmes, have you tried to install the DPDK library?" > > > Followed by an insight: "You know, the DPDK naming is weird..." > > > And we could continue the story with developers having some naming clash > > > because of some identifiers not prefixed at all. > > > > > > The goal of this email is to get some feedback on how important it is to > > fix the > > > DPDK namespace. > > > > > > 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). > > > > > > Opinions welcome! > > I don't have an opinion on how important it is to fix the namespace, > > though it does seem like a good idea. > > However if it's to be done, in my opinion it should be completed quickly > > or will just cause more confusion. > > So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should > > follow in next release or two, with > > the resulting ABI compatibility handling. Maybe with dual naming handled > > for several releases, but a > > clear end date when all are converted. > > Else there will be many years with a mix of rte_ and dpdk_ > > > > > > Googling rte functions or error codes usually takes you to dpdk dev email > archive so I don't think it is that much difficult to figure out where rte > comes from. > Other than that , except for my own refactoring pains when replacing a dpdk > version, I do not see a major reason why not. > If Going for dpdk_ prefix, I agree with the quick death approach. +1: it's a bit weird to keep both, especially for a long while, that every time we turn a rte_ prefix to dpdk_ prefix, we break applications. Instead of breaking applications many times, I'd prefer to break once. Therefore, applications could do a simple global rte_ -> dpdk_ substitute: it doesn't sound that painful then. And here are few more comments: - we should add rte_/dpdk_ prefix to all public structures as well. I'm thinking we are doing well here. I'm just aware that vhost lib does a bad job, which is something I proposed to fix in next release. - If we do the whole change once, I'd suggest to do it ASAP when this release is over. It should be a HUGE change that touches a lot of code, if we do it later, at a stage that a lot of patches for new features have been made or sent out, all of them need rebase. That'd be painful. --yliu