[dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental

Luca Boccassi bluca at debian.org
Fri Jan 17 11:46:08 CET 2020


On Fri, 2020-01-17 at 09:27 +0100, David Marchand wrote:
> On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon <
> thomas at monjalon.net
> > wrote:
> > 16/01/2020 13:42, Ferruh Yigit:
> > > On 1/16/2020 11:54 AM, Neil Horman wrote:
> > > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote:
> > > > > On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron <
> > > > > echaudro at redhat.com
> > > > > > wrote:
> > > > > > Moved RFC4115 APIs to none experimental as they have been
> > > > > > there
> > > > > > since 19.02. Also, these APIs are the same as the none
> > > > > > RFC4115 APIs.
> > > > > > 
> > > > > > Signed-off-by: Eelco Chaudron <
> > > > > > echaudro at redhat.com
> > > > > > >
> > > > > 
> > > > > There is a discussion on the OVS ml at the moment to get
> > > > > these symbols
> > > > > in the stable ABI for 19.11.
> > > > > I want to understand how this would be done.
> > > > > 
> > > > > - I take this patch in 20.02, these symbols are added in the
> > > > > 20.0.1 ABI.
> > > > > On the other hand, the 19.11 release maintains the 20.0 ABI.
> > > > > 
> > > > > Does it mean the backport adds these symbols with the 20.0
> > > > > version in
> > > > > the 19.11 branch?
> > > > > Or is 20.0.1 version acceptable / a thing we want?
> > 
> > We cannot have the symbol with different versions in different
> > releases,
> > otherwise the compatibility is broken when upgrading.
> > So we have no choice, the symbol must have version 20.0.1
> > in release 19.11.1, as in release 20.02.
> 
> Indeed, good point.
> 
> 
> > > > > - These symbol already existed in the 20.0 ABI, versioned as
> > > > > EXPERIMENTAL.
> > > > > We can go and remove these entries since we are not bound to
> > > > > preserve
> > > > > the experimental APIs.
> > > > > But, on the other hand, nothing should prevent us from
> > > > > keeping some
> > > > > aliases so that the symbols versioned EXPERIMENTAL are still
> > > > > available
> > > > > to existing users.
> > > > > 
> > > > 
> > > > I would say that choice is up to you.  If you want to alias
> > > > them to be nice to
> > > > prior users, thats fine by me. But experimental means
> > > > experimental, and so users
> > > > have to be prepared to rebuild when things change, even if that
> > > > change is
> > > > changing the version from experimental to a concrete version.
> > > > 
> > > 
> > > I would prefer to keep the alias and don't break the existing
> > > users, specially
> > > for the case experimental API is becoming mature without change.
> > 
> > I agree, it's cool to be nice :)
> 
> Luca, opinion?

I'd not only prefer it but also go as far as require it for backporting
to 19.11 - experimental means experimental, but stable means stable :-)

-- 
Kind regards,
Luca Boccassi


More information about the dev mailing list