[dpdk-dev] [PATCH 2/4] Provide initial versioning for all DPDK libraries

[Neil Horman]

On Fri, Sep 19, 2014 at 10:45:38AM +0100, Bruce Richardson wrote:
> On Mon, Sep 15, 2014 at 03:23:49PM -0400, Neil Horman wrote:
> > Add linker version script files to each DPDK library to put a stake in the
> > ground from which we can start cleaning up API's
> > 
> > Signed-off-by: Neil Horman <nhorman at tuxdriver.com>
> > CC: Thomas Monjalon <thomas.monjalon at 6wind.com>
> > CC: "Richardson, Bruce" <bruce.richardson at intel.com>
> > ---
> >  <... snip for brevity ...>
> >
> > diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> > index 65e566d..1f96645 100644
> > --- a/lib/librte_acl/Makefile
> > +++ b/lib/librte_acl/Makefile
> > @@ -37,6 +37,8 @@ LIB = librte_acl.a
> >  CFLAGS += -O3
> >  CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
> >  
> > +EXPORT_MAP := $(RTE_SDK)/lib/librte_acl/rte_acl_version.map
> > +
> >  # all source are stored in SRCS-y
> >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c
> >  
> > diff --git a/lib/librte_acl/rte_acl_version.map b/lib/librte_acl/rte_acl_version.map
> > new file mode 100644
> > index 0000000..4480690
> > --- /dev/null
> > +++ b/lib/librte_acl/rte_acl_version.map
> > @@ -0,0 +1,19 @@
> > +DPDK_1.8 {
> > +	global:
> > +	rte_acl_create;
> > +	rte_acl_find_existing;
> > +	rte_acl_free;
> > +	rte_acl_add_rules;
> > +	rte_acl_reset_rules;
> > +	rte_acl_build;
> > +	rte_acl_reset;
> > +	rte_acl_classify;
> > +	rte_acl_dump;
> > +	rte_acl_list_dump;
> > +	rte_acl_ipv4vlan_add_rules;
> > +	rte_acl_ipv4vlan_build;
> > +	rte_acl_classify_scalar;
> > +
> > +	local: *;
> > +};
> > +
> 
> Looking at this versionning, it strikes me that this looks like the perfect 
> opportunity to go to a 2.0 version number.
> 
> My reasoning:
> * We have already got fairly significant ABI and indeed API changes in this 
>   release due to the mbuf rework. That allow makes it a logical point to 
>   bump the Intel DPDK major version number to 2.0
> * Having the API versioning start at a 2.0 looks neater than having it at 
>   1.8, since .0 is a nice round version number to start with. Also if we 
>   decide in the near future for whatever reasons to go to a 2.0 release, the 
>   ABIs are probably still going to be 1.8. [Again, if we ever want to go to 
>   2.0, now looks the perfect time]
> * For the naming of the .so files, starting with them at a .2 now seems 
>   reasonable to me, denoting a clean break with the older releases which did 
>   have a different ABI. [Though again it makes more sense if you consider 
>   that we may want to move to a 2.0 in future].
> 
> What do people think?
> 
I'm fine with it.  Just so that we're clear, this patch treats versions like
arbitrary strings (the file structure denotes version ordinality), so 1.8 vs 2.0
makes absolutely no difference as far as it goes, the exported version value is
a matter of policy, but I'm fine with making that adjustment
Neil

> /Bruce
>