From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility
Date: Thu, 18 Sep 2014 20:23:36 +0200 [thread overview]
Message-ID: <2657938.GdCLzJqtVh@xps13> (raw)
In-Reply-To: <1410809031-19114-1-git-send-email-nhorman@tuxdriver.com>
Hi Neil,
2014-09-15 15:23, Neil Horman:
> The DPDK ABI develops and changes quickly, which makes it difficult for
> applications to keep up with the latest version of the library, especially when
> it (the DPDK) is built as a set of shared objects, as applications may be built
> against an older version of the library.
>
> To mitigate this, this patch series introduces support for library and symbol
> versioning when the DPDK is built as a DSO. Specifically, it does 4 things:
>
> 1) Adds initial support for library versioning. Each library now has a version
> map that explicitly calls out what symbols are exported to using applications,
> and assigns version(s) to them
>
> 2) Adds support macros so that when libraries create incompatible ABI's,
> multiple versions may be supported so that applications linked against older
> DPDK releases can continue to function
>
> 3) Adds library soname versioning suffixes so that when ABI's must be broken in
> a fashion that requires a rebuild of older applications, they will break at load
> time, rather than cause unexpected issues at run time.
>
> 4) Adds documentation for ABI policy, and provides space to document deprecated
> ABI versions, so that applications might be warned of impending changes.
>
> With these elements in place the DPDK has some support to allow for the extended
> maintenence of older API's while still allowing the freedom to develop new and
> improved API's.
>
> Implementing this feature will require some additional effort on the part of
> developers and reviewers. When reviewing patches, must be checked against
> existing exports to ensure that the function prototypes are not changing. If
> they are, the versioning macros must be used, and the library export map should
> be updated to reflect the new version of the function.
>
> When data structures change, if those structures are application accessible,
> apis that accept or return instances of those data structures should have new
> versions created so that users of the old data structure version might co-exist
> at the same time.
Thanks for your efforts.
But I feel this change has too many constraints for the current status of
the DPDK. It's probably too early to adopt such policy.
By the way, this versioning doesn't cover structure changes.
How could it be managed?
Don't you think it would be more reliable if managed by packaging?
Thank you for opening this discussion with a constructive proposal.
Let's check it later on once structures will be more stable since
performance is the most critical target.
--
Thomas
next prev parent reply other threads:[~2014-09-18 18:18 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 19:23 Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning Neil Horman
2014-09-23 10:39 ` Sergio Gonzalez Monroy
2014-09-23 14:58 ` Neil Horman
2014-09-23 16:29 ` Sergio Gonzalez Monroy
2014-09-23 17:31 ` Neil Horman
2014-09-25 18:52 ` [dpdk-dev] [PATCH 1/4 v2] " Neil Horman
2014-09-26 14:16 ` Sergio Gonzalez Monroy
2014-09-26 15:16 ` Neil Horman
2014-09-26 15:33 ` Sergio Gonzalez Monroy
2014-09-26 16:22 ` Neil Horman
2014-09-26 19:19 ` Neil Horman
2014-09-29 15:44 ` [dpdk-dev] [PATCH 1/4 v3] " Neil Horman
2014-09-30 8:13 ` Sergio Gonzalez Monroy
2014-09-30 15:18 ` [dpdk-dev] [PATCH 1/4 v4] " Neil Horman
2014-10-01 10:15 ` Sergio Gonzalez Monroy
2014-10-01 10:38 ` Neil Horman
2014-10-01 11:28 ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 2/4] Provide initial versioning for all DPDK libraries Neil Horman
2014-09-19 9:45 ` Bruce Richardson
2014-09-19 10:22 ` Neil Horman
2014-10-01 11:25 ` Sergio Gonzalez Monroy
2014-10-01 14:43 ` Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 3/4] Add library version extenstion Neil Horman
2014-10-01 11:27 ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 4/4] docs: Add ABI documentation Neil Horman
2014-10-01 16:06 ` Sergio Gonzalez Monroy
2014-09-18 18:23 ` Thomas Monjalon [this message]
2014-09-18 19:14 ` [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility Neil Horman
2014-09-19 8:57 ` Richardson, Bruce
2014-09-19 14:18 ` Venkatesan, Venky
2014-09-19 17:45 ` Neil Horman
2014-09-24 18:19 ` Neil Horman
2014-09-26 10:41 ` Thomas Monjalon
2014-09-26 14:45 ` Neil Horman
2014-09-26 22:02 ` Stephen Hemminger
2014-09-27 2:22 ` Neil Horman
2014-10-01 18:59 ` Neil Horman
2014-10-07 21:01 ` Neil Horman
2014-10-08 15:57 ` Thomas Monjalon
2014-10-08 18:46 ` Butler, Siobhan A
2014-10-08 19:09 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2657938.GdCLzJqtVh@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).