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 54C6343B05; Sun, 18 Feb 2024 17:39:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D5E9E40262; Sun, 18 Feb 2024 17:39:01 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id D7A3D4021D for ; Sun, 18 Feb 2024 17:38:59 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 4CA862011D; Sun, 18 Feb 2024 17:38:59 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] eal: provide rte attribute macro for GCC attribute X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 18 Feb 2024 17:38:57 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F22D@smartserver.smartshare.dk> In-Reply-To: <19936568.sWSEgdgrri@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] eal: provide rte attribute macro for GCC attribute Thread-Index: Adpif/29Cs3oVtv+RDy65lDt4GzRbgABo3ag References: <1708035618-14090-1-git-send-email-roretzla@linux.microsoft.com> <3556729.8hb0ThOEGa@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F22A@smartserver.smartshare.dk> <19936568.sWSEgdgrri@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" Cc: "Tyler Retzlaff" , 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 > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Sunday, 18 February 2024 16.35 >=20 > 18/02/2024 13:53, Morten Br=F8rup: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > Sent: Sunday, 18 February 2024 13.24 > > > > > > 15/02/2024 23:20, Tyler Retzlaff: > > > > Provide a new macro __rte_attribute(a) that when directly used > > > > compiles to empty for MSVC and to __attribute__(a) when using > > > GCC/LLVM. > > > > > > > > Replace direct use of __attribute__ in __rte_xxx macros where > there > > > is > > > > existing empty expansion of the macro for MSVC allowing removal > of > > > > repeated #ifdef RTE_TOOLCHAIN_MSVC per macro to expand empty. > > > > > > I'm not sure it makes sense. > > > I prefer seeing clearly what is empty with MSVC. > > > > This topic has previously been discussed in another context - adding > external libraries [1]. > > > > Like you do here, I generally preferred #ifdefs in the code, but the > majority preferred stubs "promoting improved code readability". >=20 > Stubs may make sense in many places, > but here we are talking about rte_common.h > where we abstract differences between arch and compilers, > so it is the right place to be explicit with compilers support. Very strong point. I'm convinced. Should the new rte_attribute() macro still be introduced for other uses = of __attribute__(), e.g. the somewhat exotic attributes in = eal/include/rte_lock_annotations.h? The not-so-exotic attributes could have new macros added, e.g. = __rte_const and __rte_pure. >=20 > > I might argue that Tyler is following that guidance here; and = perhaps > the decision should be reconsidered, now that we have a real-life > example of how it affects code readability. ;-) > > > > [1]: https://inbox.dpdk.org/dev/20240109141009.497807-1- > jerinj@marvell.com/ >=20 >=20