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

Bruce Richardson bruce.richardson at intel.com
Fri Sep 19 11:45:38 CEST 2014


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?

/Bruce


More information about the dev mailing list