[dpdk-dev] DPDK namespace

[Trahe, Fiona]

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Tuesday, April 05, 2016 3:13 PM
> To: Thomas Monjalon; dev at dpdk.org
> Cc: Trahe, Fiona
> Subject: RE: [dpdk-dev] DPDK namespace
> 
> 
> 
> > -----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_

An alternative: Would it not be better to do this as one specific 
namespace-change-only release, e.g. an extra 16.06 release, rather than bundling with functional changes?