Re: [dpdk-dev] DPDK namespace

[Jay Rolette <rolette@infinite.io>]

On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
wrote:

> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
> > 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.
>
> 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.
>
> - 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.
>

This last point that yliu brings up is the one that worries me. DPDK
already has a serious problem with the patch backlog. It can take months
for even small bug fixes to get merged.

>From the app side, it's not the end of the world if there is a one time,
single shot change to the prefix. However, I'm not sure it's worth it
because of the impact on patches that have been submitted. As others have
mentioned, google can sort the rte_* references just fine.

Jay