From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id DBB7F1E35 for ; Fri, 12 Jan 2018 00:17:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8281220708; Thu, 11 Jan 2018 18:17:33 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 11 Jan 2018 18:17:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=qTRHUH0xq9Rq+pJrt6w5ciaOBh 0rVnw472paoBoG2iw=; b=qO48reLMfWiYSfFBngufQVt+z5CBPvt06ATVxM31jF RLDQdmf5/nqlUF95CU4AEg2HXLGjgAolI0s0dUH76JMWsKkge4RKKpOlBhY4jA6P 670Ae9BExKQcghwcCazEb/JlibHpKzcjSvJ/Au1MCOdo1zDBdP9+ZfTeK4dscRnY I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qTRHUH 0xq9Rq+pJrt6w5ciaOBh0rVnw472paoBoG2iw=; b=mF2VTIlhrQthLBQCHkcgwz IxuAtg5+5M0uFU8YqTjYQ6qcg9jUimQRt1hVPNHW4+AxRHLNP3j/b7xnneEXFzWH 38V5Byc8YmNIKgnKRSj0DHc9TWpokSr10/7NO9J7yMx5Vpt+rM4zyVVRlUMYNlxC 51kMFMuBDgLh15H4G5t9/11i7oOipOKkawPgT5x3YnKhjHNiCEhBWu5uhnzs6wxi P7a4Yj8bvfbLsNw/ipbFZX4333LXGUsNlwzyjKvRyM7ePmXY4g90FCGKh4RfGZKI zLGZLqB68w3OhFaSpmr9SuigP34xXckif2Ky+R7lRY2DxOYaVWFT2Ptzi8O9x+zw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 1CBE37E300; Thu, 11 Jan 2018 18:17:33 -0500 (EST) From: Thomas Monjalon To: "Carrillo, Erik G" Cc: dev@dpdk.org, Aaron Conole , "pbhagavatula@caviumnetworks.com" , "Van Haaren, Harry" Date: Fri, 12 Jan 2018 00:17:05 +0100 Message-ID: <1713856.qAfyk3hvam@xps> In-Reply-To: References: <1515005015-31990-1-git-send-email-erik.g.carrillo@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/1] eal: return true or false from lcore role check function 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: , X-List-Received-Date: Thu, 11 Jan 2018 23:17:34 -0000 12/01/2018 00:09, Carrillo, Erik G: > Hi Aaron, > > From: Aaron Conole [mailto:aconole@redhat.com] > > > > Hi Erik, > > > > Erik Gabriel Carrillo 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 > > > --- > > > > 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.