From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH 1/1] eal: return true or false from lcore
	role check function
Date: Fri, 12 Jan 2018 00:17:05 +0100
Message-ID: <1713856.qAfyk3hvam@xps>
References: <1515005015-31990-1-git-send-email-erik.g.carrillo@intel.com>
 <f7ttvvv3rt4.fsf@dhcp-25.97.bos.redhat.com>
 <BE54F058557D9A4FAC1D84E2FC6D87570EDA01F5@fmsmsx115.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, Aaron Conole <aconole@redhat.com>,
 "pbhagavatula@caviumnetworks.com" <pbhagavatula@caviumnetworks.com>,
 "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: "Carrillo, Erik G" <erik.g.carrillo@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id DBB7F1E35
 for <dev@dpdk.org>; Fri, 12 Jan 2018 00:17:33 +0100 (CET)
In-Reply-To: <BE54F058557D9A4FAC1D84E2FC6D87570EDA01F5@fmsmsx115.amr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

12/01/2018 00:09, Carrillo, Erik G:
> Hi Aaron,
> 
> From: Aaron Conole [mailto:aconole@redhat.com]
> > 
> > Hi Erik,
> > 
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com> writes:
> > 
> > > Update rte_lcore_has_role() so that it returns true/false instead of
> > > success/failure.
> > >
> > > Fixes: 78666372fa2b ("eal: add function to check lcore role")
> > >
> > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> > > ---
> > 
> > I believe this breaks the published abi - Success is now 'true', and failure is
> > 'false';  previously success would be 0 == false.  You'll need to invert the test,
> > or note that the abi is breaking (since semantically any caller will need to
> > invert the test).
> 
> Good point.  Though it seems like an API change rather than an ABI change to me, would it still be handled the same way in terms of notice?  Also,  the ABI policy states, "ABI breakage due to changes such as reorganizing public structure fields for aesthetic or readability purposes should be avoided."   Perhaps I should go with an alternate patch that fixes the caller.

Most of the times, an API change is an ABI change.
Please make a deprecation notice.