>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."
As I understand RTE is from the ?Run Time Environment? which was the primary set of API?s at the time and it just kept getting propagated :-) > >> >> 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. To me rte_ is just fine, plus we have to change the structures names and defines names. I am sure we can figure out a script to convert any app for the developer, but why change. The rte_ prefix is something which can be explained and dpdk_ adds one character to type :-) > > - Panu - > Regards, Keith
