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