From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4AE99A00C2; Wed, 24 Aug 2022 09:39:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DDF3C40DFD; Wed, 24 Aug 2022 09:39:24 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 2492140DDE; Wed, 24 Aug 2022 09:39:24 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A34A05C0130; Wed, 24 Aug 2022 03:39:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 24 Aug 2022 03:39:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1661326763; x= 1661413163; bh=G4KfXnafZd0jjiqTkN6Aky2lzKXBDjhRUskt9mSjKsU=; b=s AJbBx/gh+xj6YtzVEGlEiEDWnLpo+5aRLUcVFJMUPDRgEyaU4tl46yN9OT6PflsQ fpK/DFzurV30pK8Yv21zULBeTz79Je+dLdb8reAR8sVboPHg5YmTQwBZK5QWbc7K gXxWKI0dngP2c88Hl21P6QCyIwY+mlJfv1j/gOdKlsJpdJzHdKp8v73UuADPXY7N kVXZ95FR+3lAFR8C7Ushf46SJ6EiNr3/XGJJRiMGj5VojrbJItzOL4/QocaBK5FM AigR4ncxnlexeChjUoagi9aKUkt6CbW5lOdCHhmTBYvTgpAazd6rLzyNlm0WLAq1 LRwzxqp5o9H7UrXsrxTDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1661326763; x= 1661413163; bh=G4KfXnafZd0jjiqTkN6Aky2lzKXBDjhRUskt9mSjKsU=; b=d holojaP5BavNpV3wwpTqvA+0Qu9BwOldyXxMlwFMYUAF5xCoNZtwCLk6TncvVkKC YErWwKIYWh1s3a/AfbM66KU/TsWnbi48IzmN2alr1b1HygTHmIQj2wuLOmAxiceA i+iHKFgsPvZ6fNgxLM+gxE2qU0EFqd9DfN1z2G81AhssSgOgXk9NDqWBqlmrjpwn a2OpSnho+/BuFHHlVZuSWbAKc4FvP5+0RQYJp6u74IImawiYOevGIinGAJIB40DH Y5KBezGR1Ek+QkeRybLnfPoP4HPQNniJI4hbk/DgamnmJ+iaPbERjRurZQ23r9n9 hHM0s6byc43YvPFoCOzYA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejtddguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Aug 2022 03:39:20 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , techboard@dpdk.org, David Marchand Cc: dev , Fan Zhang , Ashish Gupta , Qiming Yang , Wenjun Wu , Shijith Thotton , Srisivasubramanian Srinivasan , Chengwen Feng , Kevin Laatz , Ferruh Yigit , Andrew Rybchenko , Olivier Matz , Ori Kam , Akhil Goyal , Maxime Coquelin , Chenbo Xia Subject: Re: [RFC v3 08/26] dev: move unrelated macros from header Date: Wed, 24 Aug 2022 09:39:18 +0200 Message-ID: <3629884.MHq7AAxBmi@thomas> In-Reply-To: References: <20220628144643.1213026-1-david.marchand@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 24/08/2022 08:50, David Marchand: > On Fri, Jul 29, 2022 at 3:22 PM David Marchand > wrote: > > > > On Fri, Jul 29, 2022 at 11:59 AM Bruce Richardson > > wrote: > > > > > Personally, I really don't like these macros at all. I think having the > > > > > check explicitly in the code would be far more readable, and would only be > > > > > one line of code longer than the macro call. Is there some private header > > > > > file we could move these to instead of rte_common.h so we can drop their > > > > > use in future if we decide to? > > > > > > > > I don't like them either. > > > > Not sure where to put them though... > > > > > > > > My "grep-all" shows no user in the projects consuming DPDK I track. > > > > We could mark those macros deprecated, fix our code and drop them later. > > > > > > > +1 to that. > > > Can they be marked as deprecated as part of the move perhaps (assuming we > > > get agreement to kill them?) > > Let's see if techboard members have an opinion. These macros have no added value for an external user. I think it is OK to mark them deprecated and plan for a future removal. Copy of the code for the context: /** Macros to check for invalid function pointers. */ #define RTE_FUNC_PTR_OR_ERR_RET(func, retval) do { \ if ((func) == NULL) \ return retval; \ } while (0) #define RTE_FUNC_PTR_OR_RET(func) do { \ if ((func) == NULL) \ return; \ } while (0)