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