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 04BC7A0561; Thu, 18 Mar 2021 15:41:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 88C4F406B4; Thu, 18 Mar 2021 15:41:40 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id C34CF40698; Thu, 18 Mar 2021 15:41:38 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DEF585C00CD; Thu, 18 Mar 2021 10:41:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 18 Mar 2021 10:41:37 -0400 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= SxTapqbITIASj9mvI6G9t+rkk9RpJm4G8FTd8oCKvUk=; b=TrVr2AiVa5aYrxCY iKS9EisLWWF7JeHj7yxRV6CA4FenBFHmP0YqPrv6gPA12pZWNohCKwQuDcrZEEz5 t4qy3MVScYrpIatVskNcJGn3OrCWsuBKyxCCua5OmDQHt3bJ2A0s6r66SJaMhhYb yKIb5N+Y5TnBfYHnVBt+IQCXxtK3VRjgD3hJU8yKPYFLrHy6UuWN9S2E7nmTZh0T 8EfHnqEeE6xEfNf3m6Se4KWiIDLBEM66RORrjgNA7PrvOcAu0RcAgUs0uTgDVlQJ Pw7OTQEeYiucb0pXdb1N/AIwFsSt3HYC6Hb9toZSudnyRjkBppwKNcsIk6JXFajA wxxHjw== 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=fm2; bh=SxTapqbITIASj9mvI6G9t+rkk9RpJm4G8FTd8oCKv Uk=; b=U53y4w90XVTb1UEhT0lcstmMh5f1FLIxnxfkqamSctUXCEfRZWtUaqH8O dUFoJ+gwUGvgDb++cRqxU+sF56tl5DoF0izzF9ICiG/RzwcXgWeMMMVB+x3dJ4PI cKZjRIXJ+SIRWfjqw5iU2sAUyce3cxHVdnXEYvjsYl1VEVZN/QGgblveHY8HWpXo +yX6eaNcdOG1hc/ZfrKRlZ+LhSBkrEAlnrLpfUruakktM33eeXiBx9XZhwSEa/VK O8Tn9B8B+fRTIPD9fGCpcC9ru65o6bMmqt0sXIg77kjF217C2VtsNl2ZRETvtaDi f7K84x2ADwKJzJluFD+Cix+kctJ4A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefiedgieelucetufdoteggodetrfdotf 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 11CD024005A; Thu, 18 Mar 2021 10:41:36 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: David Marchand , dev , dpdk stable Date: Thu, 18 Mar 2021 15:41:35 +0100 Message-ID: <2329735.2CMtTcrZrs@thomas> In-Reply-To: <20210318122827.GB1633@bricha3-MOBL.ger.corp.intel.com> References: <20210317093124.965624-1-thomas@monjalon.net> <10994121.sJyVhAAg4N@thomas> <20210318122827.GB1633@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] [PATCH] eal: fix version macro 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" 18/03/2021 13:28, Bruce Richardson: > On Wed, Mar 17, 2021 at 11:01:25AM +0100, Thomas Monjalon wrote: > > 17/03/2021 10:48, David Marchand: > > > On Wed, Mar 17, 2021 at 10:31 AM Thomas Monjalon wrote: > > > > > > > > The macro RTE_VERSION is broken since updated with function calls. > > > > It is a build-time version number, and must be built with macros. > > > > For a run-time version number, there is the function rte_version(). > > > > > > > > Fixes: 5b637a848195 ("eal: fix querying DPDK version at runtime") > > > > Cc: stable@dpdk.org > > > > > > > > Reported-by: David Marchand > > > > Signed-off-by: Thomas Monjalon > > > > --- > > > > lib/librte_eal/include/rte_version.h | 8 ++++---- > > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/lib/librte_eal/include/rte_version.h b/lib/librte_eal/include/rte_version.h > > > > index 2f3f727b46..736c5703be 100644 > > > > --- a/lib/librte_eal/include/rte_version.h > > > > +++ b/lib/librte_eal/include/rte_version.h > > > > @@ -28,10 +28,10 @@ extern "C" { > > > > * All version numbers in one to compare with RTE_VERSION_NUM() > > > > */ > > > > #define RTE_VERSION RTE_VERSION_NUM( \ > > > > - rte_version_year(), \ > > > > - rte_version_month(), \ > > > > - rte_version_minor(), \ > > > > - rte_version_release()) > > > > + RTE_VER_YEAR, \ > > > > + RTE_VER_MONTH, \ > > > > + RTE_VER_MINOR, \ > > > > + RTE_VER_RELEASE) > > > > > > > > /** > > > > * Function to return DPDK version prefix string > > > > > > The original patch wanted to fix rte_version() at runtime. > > > I don't see the need to keep the rte_version_XXX exports now that > > > RTE_VERSION is reverted. > > > > I think it may help to query the version numbers at runtime, > > in "if" condition. Is there another way I'm missing? > > We may argue that the runtime version number should not be used > > to decide how to behave in an application. > > > I would also tend toward keeping them, for the same reason that runtime is > definitely to be preferred over build time, and they are not like to be > much of a maintenance burden. > > Also, next time we have an ABI break, I wonder if the existing macros > should be renamed to have an RTE_BUILD_VER_ prefix, to make it clear that > it's the build version only that is being reported rather than the version > actually being used. Similarly the functions could be renamed to have > rte_runtime_ prefix, ensuring that in all cases the user is clear whether > they are getting the build version or the runtime version. I am fine with such rename, but that's already quite clear that a macro is at build time, and a function is usually evaluated at runtime.