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 >
