From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by dpdk.org (Postfix) with ESMTP id EFB049E7 for ; Tue, 5 Apr 2016 16:31:22 +0200 (CEST) Received: by mail-ob0-f174.google.com with SMTP id fp4so10430032obb.2 for ; Tue, 05 Apr 2016 07:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RJ6Ei7xytZWiZTcCkyjizLBOeABT6e8/JiVxWpZBM5U=; b=DT789N9epNpmnBDKwEZuXyYRbsCfa4KsSg7U7OchNOUOIQ90paXrzl7rOdHhwHKPsX lv6d/fJwdaCm9y3KUF6why46gwje0FPQdXrNfCKShYWWDEkYSow/a/Zv2fGvmQByD11m J1BqdZhKqNHL2UIQbm/LKBYIU8vxb0EaPHooVtef0IrU2JjKDy4lbJLW0bjXAtlfhV5n xD2gV6JMnUw67hFmzIf0rwGuxDhfIsebfJkNnWeLex0btHnI+9/zKiAAtFUCqYRpw4Td keYwu6JbHi4SkdCbyaAoRoOI4z1ro8H0Hu1gtiWESxf6vmMjTZj3gey/fKZu/52H5wu6 KB4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RJ6Ei7xytZWiZTcCkyjizLBOeABT6e8/JiVxWpZBM5U=; b=Vlr4by34GxelaCaEq39DC5JxTcwni2PfXd/qpQoaMwCQCftEej/ayS7cTRRkBjFVYx wJmhWdG2nlYMgvasSBJDs4CvFuZlCp/guH915PEb8lFTI1QFbEa/phDtr83xaTgrMltN dPezP78fBkUAErSTyFwpNy063M3ddhFUEUZwG2fDhSgtbni0Lxah+NtNTD7KUiOu7XBi FRvHwzKVqeMn+I05NP483R9BTJG76LiF+5/LWm8D9N3yAivSkV2bIlMat8no8A5udasU 33vBUbA9R49bjf2VDu9xvtJBm8vpHCYY9+gEt5xGIxwOck4a9Kh4+QXh1vQi2VVO8o4c Lg/A== X-Gm-Message-State: AD7BkJLKSLpFDFfCaEyxhuWRg8a+yMSXL7HxNorMjHNvI4QCccYhEuAcYD3bdRoA+ZrqVmwVErETj2TpUlkMwA== MIME-Version: 1.0 X-Received: by 10.60.156.103 with SMTP id wd7mr13603736oeb.47.1459866682484; Tue, 05 Apr 2016 07:31:22 -0700 (PDT) Received: by 10.202.104.148 with HTTP; Tue, 5 Apr 2016 07:31:22 -0700 (PDT) In-Reply-To: <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> References: <1610488.T03Kyi0Reo@xps13> <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com> Date: Tue, 5 Apr 2016 17:31:22 +0300 Message-ID: From: Arnon Warshavsky To: "Trahe, Fiona" Cc: Thomas Monjalon , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:31:23 -0000 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. /Arnon