From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 2B6CD20F for ; Tue, 7 Jul 2015 15:12:02 +0200 (CEST) Received: from voip-107-15-76-160.kyn.rr.com ([107.15.76.160] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZCSfF-0004s6-UG; Tue, 07 Jul 2015 09:12:00 -0400 Date: Tue, 7 Jul 2015 09:11:57 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20150707131157.GB6932@hmsreliant.think-freely.org> References: <1435874746-32095-1-git-send-email-thomas.monjalon@6wind.com> <33405606.8BIq3zMLWK@xps13> <20150707111441.GA6932@hmsreliant.think-freely.org> <2767225.WkjHcd5aCI@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2767225.WkjHcd5aCI@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: enable next abi in static libs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 13:12:02 -0000 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 > > -version-next.map to -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 >