From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 40D82A0524; Thu, 30 Jan 2020 17:04:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 08C051C022; Thu, 30 Jan 2020 17:04:52 +0100 (CET) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 11CD11BFD1 for ; Thu, 30 Jan 2020 17:04:50 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id q9so4348505wmj.5 for ; Thu, 30 Jan 2020 08:04:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=OmwIxcyh4wFf2YAkMkMP8/Ra+6x0x5n4swvphN+b1oc=; b=hiK8Dto5BvwpjLvBl8ngJYjGW3iHmncPkjqU6RNsvGtmJgWK6hF4jDyjP4wm3lnsUX tXFgbG+YFedwbgiixisHUEA3ISwDGpP01xOGUP/76xeQOCZeuqeYB+qJWcJKuTHq2gnG 8AniSbyl/OaYFTAhJvnHTTOHJbmK3cbJAIxllP9y/H0FjjaMVa5+IzZF1vLkD905DXfN IA1qU07yfQXk0bzXpfe8/Q66EsKfn79h/NxaDLGUkT/pN6q4VJcpSwgaI8ZVUA7ATd1x iWhhu6k3l9PsqKONRk+NOb//x3h1FqiO0itsUAONSyfTPSVZeNvQknIahZuU7F9lnttq yqRA== X-Gm-Message-State: APjAAAUIxNeuiAApEn7lHhWNVIKp8JqY8ey6ID0obpVDFA65mv35epRr GyMvpzJGxh0yI9ZjRtifBeI= X-Google-Smtp-Source: APXvYqz/aluxlxeuBVgg+L8o/KZuRTkyHxdYkVahRQkXHbgSPQPy8RPAyBGp94YqlBctQH4hrsXYpA== X-Received: by 2002:a05:600c:2942:: with SMTP id n2mr6207967wmd.87.1580400289796; Thu, 30 Jan 2020 08:04:49 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id x7sm7927091wrq.41.2020.01.30.08.04.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jan 2020 08:04:48 -0800 (PST) Message-ID: <3a08271e0d811359f7dc1cc732b6bdc89cc98a4e.camel@debian.org> From: Luca Boccassi To: Thomas Monjalon Cc: Ferruh Yigit , Neil Horman , Cristian Dumitrescu , Eelco Chaudron , dev@dpdk.org, David Marchand , Bruce Richardson , Ian Stokes , Andrzej Ostruszka Date: Thu, 30 Jan 2020 16:04:47 +0000 In-Reply-To: <5634584.alqRGMn8q6@xps> References: <20200129122953.2016199-1-ferruh.yigit@intel.com> <1929128.8hb0ThOEGa@xps> <71b93a9bbebf1f047f24d3f455eab1bf2712dcf4.camel@debian.org> <5634584.alqRGMn8q6@xps> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC v2] meter: fix ABI break due to experimental tag removal X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote: > 30/01/2020 15:21, Luca Boccassi: > > On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote: > > > 30/01/2020 13:57, Luca Boccassi: > > > > On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote: > > > > > Hi, > > > > >=20 > > > > > I disagree with the need of this patch. > > > > > The symbol was experimental, meaning we can change it. > > > > > Removing experimental tag is not an ABI break. > > > >=20 > > > > Hi, > > > >=20 > > > > This symbol change was requested for backport in 19.11.x, and > > > > experimental or not I'm not too keen on backward incompatible > > > > changes > > > > to the public interface in an _LTS point release_. The > > > > compromise > > > > was > > > > to see if we could support both symbols version, which makes > > > > the > > > > change > > > > backward compatible. > > > >=20 > > > > If you prefer not to have this patch in mainline I'm also fine > > > > in > > > > taking it just for the LTS. I agree with you that it is not > > > > required > > > > for mainline releases (although nicer for me if it's a backport > > > > rather > > > > than a new change). > > >=20 > > > I would like to avoid opening the door for maintaining the > > > experimental ABI > > > in the mainline. Please take it directly in the LTS. > > >=20 > > > The next question is to know whether we really want to have such > > > patch in LTS. > > > Anyway, 19.11.0 has this symbol as experimental. > > > How adding a non-experimental version of the function in 19.11.1 > > > will > > > change > > > the ABI status of the whole 19.11 branch? > >=20 > > The problem is not adding the new symbol, but removing the > > experimental > > one. Changing the version of the symbol was requested by OVS for > > inclusion in 19.11. >=20 > Yes, sorry, this is what I meant. > Given 19.11.0 already has the symbol as experimental, > and that applications like OVS had to accept it as experimental, > why removing experimental tag in 19.11.1? I think it was mentioned that it was preferred not to suppress the compiler warning to avoid any accidental use in the future, but the OVS maintainer(s) should answer as I might remember wrongly. --=20 Kind regards, Luca Boccassi