[dpdk-dev] DPDK namespace

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces at 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 at 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 at intel.com> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> >>>> Sent: Tuesday, April 05, 2016 2:57 PM
> >>>> To: dev at 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