[dpdk-dev] DPDK namespace

[Panu Matilainen]

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.

	- Panu -