From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Panu Matilainen <pmatilai@redhat.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Arnon Warshavsky <arnon@qwilt.com>
Cc: "Trahe, Fiona" <fiona.trahe@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK namespace
Date: Wed, 6 Apr 2016 12:34:31 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836B2EB28@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <5704FC10.8020405@redhat.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, April 06, 2016 1:08 PM
> To: Yuanhan Liu; Arnon Warshavsky
> Cc: Trahe, Fiona; Thomas Monjalon; dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK namespace
>
> 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 <fiona.trahe@intel.com> 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 <insert excuse here, probably early project
> name> 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.
>
Yep, I have exactly the same thoughts:
1. Yes, dpdk_' prefix is a better naming approach than 'rte_',
but for me not that better to overweight all the pain of such big change.
2. If we still decide to do that change - my preference would be to do it in one go.
I personally don't care that much what the prefix would be, as long as it is consistent
across the whole codebase.
Konstantin
next prev parent reply other threads:[~2016-04-06 12:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 13:56 Thomas Monjalon
2016-04-05 14:13 ` Trahe, Fiona
2016-04-05 14:31 ` Trahe, Fiona
2016-04-05 14:31 ` Arnon Warshavsky
2016-04-06 5:26 ` Yuanhan Liu
2016-04-06 12:07 ` Panu Matilainen
2016-04-06 12:34 ` Ananyev, Konstantin [this message]
2016-04-06 14:36 ` Wiles, Keith
2016-04-06 20:21 ` Dave Neary
2016-04-07 8:22 ` Marc
2016-04-11 16:10 ` Don Provan
2016-04-11 16:28 ` Thomas Monjalon
2016-04-06 12:41 ` Jay Rolette
2016-04-06 12:51 ` Mcnamara, John
2016-04-07 9:18 ` Thomas Monjalon
2016-04-07 9:33 ` Panu Matilainen
2016-04-07 10:16 ` Marc Sune
2016-04-07 11:51 ` [dpdk-dev] On DPDK ABI policy Panu Matilainen
2016-04-07 21:52 ` Matthew Hall
2016-04-08 8:29 ` Marc Sune
2016-04-08 8:47 ` Marc Sune
2016-04-07 21:48 ` [dpdk-dev] DPDK namespace Matthew Hall
2016-04-07 22:01 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725836B2EB28@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=arnon@qwilt.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
--cc=pmatilai@redhat.com \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).