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: Tue, 7 Jul 2015 09:11:57 -0400 [thread overview]
Message-ID: <20150707131157.GB6932@hmsreliant.think-freely.org> (raw)
In-Reply-To: <2767225.WkjHcd5aCI@xps13>
On Tue, Jul 07, 2015 at 05:46:08AM -0700, Thomas Monjalon wrote:
> Thanks Neil, we are making good progress.
>
> 2015-07-07 07:14, Neil Horman:
> > On Mon, Jul 06, 2015 at 11:44:59PM +0200, Thomas Monjalon wrote:
> > > 2015-07-06 14:22, Neil Horman:
> > > > On Mon, Jul 06, 2015 at 03:49:50PM +0200, Thomas Monjalon wrote:
> > > > > 2015-07-06 09:35, Neil Horman:
> > > > > > 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.
> > > [...]
> > > > I'd be ok with it iff:
> > > >
> > > > 1) It applies to static and shared ABI's together. That is to say that setting
> > > > the NEXT_ABI config flag creates the same ABI changes regardless of other build
> > > > configuration. It needs to be used in such a way that a consistent ABI is
> > > > presented when set, otherwise it won't be useful.
> > >
> > > Yes the option trigger exactly the same ABI for static and shared libraries.
> > > But it's too complicated (at least for 2.1) to make LIBABIVER and version map
> > > dependant of this build-time option.
> >
> > No, I think thats a bridge too far. I'm not sure whats difficult about
> > overriding LIBABIVER in lib.rte.mk and bump all numbers 1 higher (or better
> > still just add a .1 to the end of it), by checking CONFIG_NEXT_ABI
>
> Good idea, I will submit a v2 which adds .1.
>
> > As for maintaining the version map, I don't see any problem with duplicating the
> > map files, to a -next variant, and changing the CPU_LDFLAGS in rte.lib.mk based
> > on the NEXT_ABI config option again.
>
> OK
>
> > In fact, if this is a thing that people want, that might be beneficial, as
> > something else occurs to me. I think you're going to want this to be a mandated
> > piece of the update process. That is to say, if someone wants to deprecate an
> > aspect of the ABI, or change it, I think you'll want to mandate that they submit
> > the change at the same time they submit the deprecation notice, and simply
> > protect it with this NEXT_ABI config option. That provides several advantages:
>
> For the release 2.1, we have some deprecation notices without code. It was
> the policy agreed in 2.0 release.
Right, we're stuck with that for the next release, but this idea of yours I
think will help make sure we get both together in the future.
> Maybe we can force code to be submitted with deprecation notices, starting
> with release 2.2.
> It needs to be amended in v2 of this patch.
Yes, I think that makes sense
>
> > 1) It ensures that the notice is submitted at the same time as the actual change
> > 2) It ensures that the NEXT_ABI provides a complete view of what the next ABI
> > version looks like, not just a partial view of it
>
> Yes it would be probably useful.
>
> > Adding a *-version-next.map file for each library makes adhering to the above
> > easier, and allows for an easy converstion, in that when its time to officially
> > update the ABI, fixing the version map is a matter of copying
> > <library>-version-next.map to <library>-version.map.
>
> OK
>
> [...]
> > > That's why, it should not be enabled to deploy shared libraries, though it can
> > > be used for tests and development.
> > > As static libraries are almost never packaged, they will be built and linked
> > > at the same time. That's why users of static libraries tend to prefer the
> > > newest ABI, which is the default in this case.
> > >
> > > > 2) It only applies to the next ABI. That is to say, it can't be a hodgepodge of
> > > > the next ABI and the one after that, and the one after that, or it won't provide
> > > > an appropriate preview for anyone.
> > >
> > > If you mean the next ABI must be promoted as the standard ABI in the next release,
> > > yes: ifdefs will be cleaned when starting a new release.
> > > Thanks, I learnt the english word hodgepodge :)
> > >
> > Je-mexcuse, une meli-melo? :)
>
> Oui un meli-melo, un ramassis. un beau bordel en somme.
>
exactement! :)
> > I mean't what you indicate yes, and in addition to that, I just wanted to
> > clarify that this option could strictly _only_ apply to the very next ABI. That
> > is to say, someone can't use this without also posting an ABI deprecation
> > notice, or we would find ourselves in a situation where something would only be
> > available in NEXT_ABI for more than one release, which would be unacceptable.
> > But I think we're saying the same thing.
>
> Yes. I'll try to make it clear in v2.
>
> Neil, in the meantime, could you please help to check ABI breakage in the HEAD?
I'll try to take a look today
Neil
>
next prev parent reply other threads:[~2015-07-07 13:12 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
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 [this message]
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=20150707131157.GB6932@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).