[dpdk-dev] DPDK namespace

[Yuanhan Liu]

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.

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.

- 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.

	--yliu