[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