DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: enable next abi in static libs
Date: Mon, 6 Jul 2015 09:35:44 -0400	[thread overview]
Message-ID: <20150706133544.GA30816@hmsreliant.think-freely.org> (raw)
In-Reply-To: <10048439.cxXN29b43P@xps13>

On Mon, Jul 06, 2015 at 03:18:51PM +0200, Thomas Monjalon wrote:
> Any comment or ack?
> 
> 2015-07-03 00:05, Thomas Monjalon:
> > When a change makes really hard to keep ABI compatibility,
> > instead of waiting next release to break the ABI, it is smoother
> > to introduce the new code and enable it only for static libraries.
> > The flag RTE_NEXT_ABI may be used to "ifdef" the new code.
> > When the release is out, a dynamically linked application can use
> > the new shared libraries without rebuild while developpers can prepare
> > their application for the next ABI by reading the deprecation notice
> > and easily testing the new code.
> > When starting the next release cycle, the "ifdefs" will be removed
> > and the ABI break will be marked by incrementing LIBABIVER.
> > 
> > The new option CONFIG_RTE_NEXT_ABI is not defined in the configuration
> > templates because it is deduced from CONFIG_RTE_BUILD_SHARED_LIB.
> > It is automatically enabled for static libraries and disabled for
> > shared libraries.
> > It can be forced to another value by editing the generated .config file.
> > It shouldn't be enabled for shared libraries because it would break the
> > ABI without changing the version number LIBABIVER. That's why a warning
> > is printed in this case.
> > 
> > The guideline is also updated to integrate this new possibility.
> > 
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> 
> 
Yeah, I'm not sure why this is necessecary.  That is to say, if you want to
introduce a new ABI operation prior to the old one being removed, that is precisely what
the versioning macros are for, and can be used to map the static api to the new
version. e.g, given function X that you want to enhance in an ABI breaking way:

1) Separate function X to X_v1 and X_v2
2) Map X_v2 to X@DPDK_v2, map X_v1 to X@DPDK_v1
3) Map the static symbol X to X_v2
4) Post the deprecation notice of X for release 3 immediately

Splitting the static ABI from the shared ABI just means that applications will
have the opportunity to isolate themselves to one kind of build, which is a bad
idea.

Neil

  reply	other threads:[~2015-07-06 13:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02 22:05 Thomas Monjalon
2015-07-06 13:18 ` Thomas Monjalon
2015-07-06 13:35   ` Neil Horman [this message]
2015-07-06 13:49     ` Thomas Monjalon
2015-07-06 18:22       ` Neil Horman
2015-07-06 21:44         ` Thomas Monjalon
2015-07-07 11:14           ` Neil Horman
2015-07-07 12:46             ` Thomas Monjalon
2015-07-07 13:11               ` Neil Horman
2015-07-07 13:44               ` Neil Horman
2015-07-10 16:07                 ` Mcnamara, John
2015-07-11 14:19                   ` Neil Horman
2015-07-13 10:14                     ` Mcnamara, John
2015-07-08 14:55 ` [dpdk-dev] [PATCH v2 0/2] next abi option Thomas Monjalon
2015-07-08 14:55   ` [dpdk-dev] [PATCH v2 1/2] mk: remove variables identical to config ones Thomas Monjalon
2015-07-08 14:55   ` [dpdk-dev] [PATCH v2 2/2] mk: enable next abi preview Thomas Monjalon
2015-07-08 16:44     ` [dpdk-dev] [PATCH v3] " Thomas Monjalon
2015-07-13  7:32       ` Mcnamara, John
2015-07-13  8:48         ` Thomas Monjalon
2015-07-13  9:02           ` [dpdk-dev] [PATCH] mk: fix shared lib build with stable abi Thomas Monjalon
2015-07-13  9:24             ` Mcnamara, John
2015-07-13  9:32               ` Thomas Monjalon
2015-07-08 16:50   ` [dpdk-dev] [PATCH v2 0/2] next abi option Neil Horman
2015-07-08 22:58     ` Thomas Monjalon

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=20150706133544.GA30816@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.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).