From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D09572C1A for ; Tue, 5 Apr 2016 16:32:23 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 05 Apr 2016 07:31:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,444,1455004800"; d="scan'208";a="938726042" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga001.fm.intel.com with ESMTP; 05 Apr 2016 07:31:17 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.157]) by IRSMSX104.ger.corp.intel.com ([169.254.5.87]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 15:31:16 +0100 From: "Trahe, Fiona" To: Thomas Monjalon , "dev@dpdk.org" CC: "Trahe, Fiona" Thread-Topic: [dpdk-dev] DPDK namespace Thread-Index: AQHRj0Nq2Ii/7nNb2U68lXjXLRuufJ97aWtwgAAGvBA= Date: Tue, 5 Apr 2016 14:31:16 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43588FC6289@IRSMSX101.ger.corp.intel.com> References: <1610488.T03Kyi0Reo@xps13> <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjYzMmVhYWMtZWUwNi00ODBhLTgxZmYtNGNhOTlkMWI3NWYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp4WU5BTUlZQlY0NkpzUytiaVpqSmdCaitJTWY4N3AxbjFRUTJhQ1wvU2tNPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 05 Apr 2016 14:32:24 -0000 > -----Original Message----- > From: Trahe, Fiona > Sent: Tuesday, April 05, 2016 3:13 PM > To: Thomas Monjalon; dev@dpdk.org > Cc: Trahe, Fiona > Subject: RE: [dpdk-dev] DPDK namespace >=20 >=20 >=20 > > -----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 b= y the > DPDK. > > Hopefully it will be explained on StackOverflow that RTE stands for DPD= K. > > Then someone else will try to run a binary without having installed > > the DPDK libraries. The linker will require libethdev.so (no prefix her= e). > > 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, thou= gh 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 fol= low 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 a= re > converted. > Else there will be many years with a mix of rte_ and dpdk_ An alternative: Would it not be better to do this as one specific=20 namespace-change-only release, e.g. an extra 16.06 release, rather than bun= dling with functional changes?