From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2630D2C08 for ; Wed, 6 Apr 2016 14:07:47 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 73D3880086; Wed, 6 Apr 2016 12:07:46 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-68.ams2.redhat.com [10.36.7.68]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u36C7i0K005549; Wed, 6 Apr 2016 08:07:44 -0400 To: Yuanhan Liu , Arnon Warshavsky References: <1610488.T03Kyi0Reo@xps13> <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> <20160406052656.GT3080@yliu-dev.sh.intel.com> Cc: "Trahe, Fiona" , Thomas Monjalon , "dev@dpdk.org" From: Panu Matilainen Message-ID: <5704FC10.8020405@redhat.com> Date: Wed, 6 Apr 2016 15:07:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160406052656.GT3080@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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 12:07:47 -0000 On 04/06/2016 08:26 AM, Yuanhan Liu wrote: > 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. I concur. If (and I think that should be a pretty big IF) the prefix is to be changed then its better done in one fast sweep than gradually. Gratuitious (or nearly so) change is always extremely annoying, and the longer it takes the more painful it is. Application developers wont much care what the prefix is as long as its consistent, but if they're forced to track prefix changes across several releases with different libraries moving at different pace, they WILL be calling for bloody murder :) As for rte_ being strange for DPDK - yes it is, but it takes like 5 minutes to get over it. It would help to have it explained on dpdk.org FAQ: "Due to historical reasons, DPDK libraries are prefixed rte_ instead of dpdk_ because and changing it is unnecessarily painful." > > 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. Yup, all public symbols should be prefixed. What the exact prefix is isn't that important really. > > - 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. Nod, that's yet another aspect to consider. So to summarize, I'm not strongly opposed to doing a one-time mass rte_ -> dpdk_ prefix change, but it needs to be one big sweep all at once, or not do it at all. Gradual change is a suicide. Keeping rte_ is not the end of the world by any means, especially when applied consistently and explained someplace. - Panu -