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 1268043B57; Tue, 20 Feb 2024 18:50:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F046D40685; Tue, 20 Feb 2024 18:50:45 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 9B24240685 for ; Tue, 20 Feb 2024 18:50:44 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id F23F02083617; Tue, 20 Feb 2024 09:50:43 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com F23F02083617 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1708451443; bh=fZRgBTavW/QmBYeD1Md+lexi51kCv+SS+4xk9aKy42M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BHaXuZBNt/MnMRAeCRMVO5J16fpA7PTO5HMgzpw04iIpwTbnd5UOoS988mbaycwj6 mTDxJqnd/5eVtUd4rSmnT8uNqkCgZHK0EIMRAdQ16ytc1zBpzJWXHmgWlDZkBlRHVo OPJB3kR8XRtmTPeDzuwHYAVg12fG9L/Y3YmaKS8Q= Date: Tue, 20 Feb 2024 09:50:43 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org Subject: Re: [PATCH] eal: provide rte attribute macro for GCC attribute Message-ID: <20240220175043.GA19214@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1708035618-14090-1-git-send-email-roretzla@linux.microsoft.com> <19936568.sWSEgdgrri@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F22D@smartserver.smartshare.dk> <4204295.tIAgqjz4sF@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4204295.tIAgqjz4sF@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Sun, Feb 18, 2024 at 05:44:48PM +0100, Thomas Monjalon wrote: > 18/02/2024 17:38, Morten Brørup: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > Sent: Sunday, 18 February 2024 16.35 > > > > > > 18/02/2024 13:53, Morten Brørup: > > > > > 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". > > > > > > 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? > > They are all wrapped in a meaningful macro. > > > The not-so-exotic attributes could have new macros added, e.g. __rte_const and __rte_pure. > > Yes we need wrappers for all attributes. These are my expectation of what is supposed to be done based on the comments in checkpatches.sh. The intention would be that __rte__attribute not be directly used outside of rte_common.h (as is required for __attribute__). Introducing __rte_attribute was an attempt by me to appease previous complaints of there being a conditional MSVC check for many macros which was triggered by finding bare use of __attribute__ elsewhere contradicting what was commented in checkpatches.sh > > > > > > 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/ > >