[dpdk-dev] DPDK namespace

Marc marcdevel at gmail.com
Thu Apr 7 10:22:50 CEST 2016


On 6 April 2016 at 22:21, Dave Neary <dneary at redhat.com> wrote:

> Hi,
>
> On 04/06/2016 08:07 AM, Panu Matilainen wrote:
> >> +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.
>

+1

Either all types and symbols use dpdk_ or rte_. It probably makes more
sense dpdk_, but to me it is not that important.

If it has to be changed, it might be a good idea to do it in this release,
now that version numbering format also changes.

>
> > 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 :)
>
> How about the idea of creating (at switch over time) an optionally
> installable dpdk_compat package that just has a list of #defines for the
> old symbols pointing them at the new symbols? That would also allow
> people with old applications to update DPDK without having to modify
> their applications.
>

You would also have to add all typedefs for type names.

Why bothering? Moving from 2.2 to 16.04 requires recompiling your
application (ABI changes), and is as simple as sed -e 's/rte_/dpdk_/g' in
all the application code base.

Marc


>
> Thanks,
> Dave.
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>


More information about the dev mailing list