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 3FC5FA09E4; Fri, 29 Jan 2021 09:54:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DDE4C240116; Fri, 29 Jan 2021 09:54:07 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 8E3E840694; Fri, 29 Jan 2021 09:54:06 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D75DF5C0208; Fri, 29 Jan 2021 03:54:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 29 Jan 2021 03:54:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= 6X8P7J3NRr/FEKk46Lbcjk7wTzY7w+knF7tl7tlpu98=; b=rzoCeKjZ8d/LrY7N EzSvO3YvJCl9+nTOvELTaFHrn+j3Ij/nzY2uQDLVqZHtsmXhIsaZ9X/NhacThMDg zkBMzkDXxUoNTr19OUNq/6kqPyBuxJ5GvShZN5bb3kDxmxL+OotCbOSeuFOPXu+e BO97iISWT2AY1t+thm05Bavh9Q7u4q47tITASNvowt1TYnp7yOffMHDa45eKLN2T ofurqNK9piZJJdG3Mev9Q/vay+wNddjezdRN9bVYH6J5pN5D1sa7Ln8B6R/+ufRq vQyTtAIWIsYEdN7oPy5oBV0R/QEKth2JHQne/Ag8MJrUW2GFTM4mEbRRE23hh44r hf+rxA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6X8P7J3NRr/FEKk46Lbcjk7wTzY7w+knF7tl7tlpu 98=; b=VVrokZNxqUiZ4Fua4f6J37nqh1uhz6WSzz83ypkgXJ4TbkAweG47I3e28 54W15j1PLiPzgoltv0r8R+nn/AI5wyWp2ozUP1H0xYKqFGcQNM08SJgPgsVGRkZB H+Ctk/RARqbZ58gp8AsWqrnQJlcA7AaguCkANyH98fdQTb7bIHkpMGcjJKG3liWT dO8/UNvYbqHNzj8OrXV3VT4DAur4WsU/f4wfdpbBrwbFZs8UluoOswqMOitCT9ts w/m8la2k8v9ELLryY9tBatulyITJDnTeJAEMY+ITHaWUegYPnp2/5XTnNUwWkw10 r3w4LOAU9XwiOU78Veh3hEvF7q2ww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedugdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C6647240057; Fri, 29 Jan 2021 03:54:03 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , David Marchand Cc: techboard@dpdk.org, dev Date: Fri, 29 Jan 2021 09:54:01 +0100 Message-ID: <5134619.so0YE94iNX@thomas> In-Reply-To: References: <20210114110606.21142-1-bruce.richardson@intel.com> <20210128173619.GL899@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH v6 2/8] eal: fix error attribute use for clang 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 Sender: "dev" 29/01/2021 09:35, David Marchand: > On Thu, Jan 28, 2021 at 6:36 PM Bruce Richardson > wrote: > > > > > > We will never know about those compilers behavior, like how we caught > > > > > > the clang issue and found an alternative. > > > > > > > > > > > > > > > > So I understand, but I'm still concerned about breaking something that was > > > > > previously working. It's one thing a DPDK developer catching issues with > > > > > clang, quite another a user catching it when trying to build their own > > > > > application. > > > > > > > > > > We probably need some other opinions on this one. > > > > > > > > > Adding Tech-board to see if we can get some more thoughts on this before I do > > > > another revision of this set. > > > > > > What are the alternatives? > > > > > > > The basic problem is what to do when a compiler is used which does not support > > the required macros to flag an error for use of an internal-only function. > > For example, we discovered this because clang does not support the #error > > macro. > > *attribute* > > > > > In those cases, as I see it, we really have two choices: > > > > 1 ignore flagging the error and silently allow possible use of the internal > > function. > > 2 have the compiler flag an error for an unknown macro > > > > The problem that I have with #2 is that without knowing the macro, the > > compiler will likely error out any time a user app includes any header with > > an internal function, even if the function is unused. > > > > On the other hand, the likelihood of impact if we choose #2 and do error out is > > quite small, since modern clang versions will support the modern macro > > checks we need, and just about any gcc versions we care about are going to > > support #error. If there are very small chances of hitting the issue, it looks acceptable. But I don't really like risking issues with not tested compilers. > > For #1, the downside is that we will miss error checks on some older > > versions of gcc e.g. RHEL 7, and the user may inadvertently use an internal > > function without knowing it. The function is marked as internal. If the user misses this info and test only with compilers not supporting the attribute, that's no luck. What would be the consequence? Having a risk for future compatibility? It looks to be an acceptable risk. The other consequence it that we won't have reports for this rare incompatibility. > > David, anything else to add here? > > Nop, fair summary. My preference is for #1: pro: No compilation will be impacted in the field con: DPDK developers may miss some cases Any other opinion?