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 270A5A0A0C; Thu, 15 Apr 2021 10:25:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFCF51620F6; Thu, 15 Apr 2021 10:25:53 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 0F658161D55 for ; Thu, 15 Apr 2021 10:25:50 +0200 (CEST) IronPort-SDR: LpP1B1zAafbsEZUJOg3VzYnbT40P5RsxK6XnpJxXHbXjWQ5+EiRi0Qu3cdGCv/HKC55uguA0f9 JOC4PESyGlug== X-IronPort-AV: E=McAfee;i="6200,9189,9954"; a="191623871" X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="191623871" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 01:25:26 -0700 IronPort-SDR: 2oR7xM219uS0whmqq8O6u1DD9lmOiG36S+WjMg6Ro61+fvHRQi/UoNd+4I9wI9mr2Yttp+rWEC ihdGlBdtnprg== X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="418665621" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.6.228]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Apr 2021 01:25:21 -0700 Date: Thu, 15 Apr 2021 09:25:17 +0100 From: Bruce Richardson To: David Marchand Cc: Akhil Goyal , Jerin Jacob Kollanukkaran , Thomas Monjalon , dev , Ray Kinsella , Abhinandan Gujjar , Hemant Agrawal , Nipun Gupta , Sachin Saxena , Anoob Joseph , Matan Azrad , Fan Zhang , Gagandeep Singh , Erik Gabriel Carrillo , "Jayatheerthan, Jay" , Pavan Nikhilesh Bhagavatula , Van Haaren Harry , Shijith Thotton , Dodji Seketeli Message-ID: <20210415082517.GA1815@bricha3-MOBL.ger.corp.intel.com> References: <20210414122036.1262579-2-gakhil@marvell.com> <20210414180417.1263585-1-gakhil@marvell.com> <20210414180417.1263585-2-gakhil@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v10 1/4] devtools: add exception for reserved fields 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" On Thu, Apr 15, 2021 at 09:26:38AM +0200, David Marchand wrote: > On Thu, Apr 15, 2021 at 7:33 AM Akhil Goyal wrote: > > > > Hi David, > > > > Certain structures are added with reserved fields > > > > to address any future enhancements to retain ABI > > > > compatibility. > > > > However, ABI script will still report error as it > > > > is not aware of reserved fields. Hence, adding a > > > > generic exception for reserved fields. > > > > > > > > Signed-off-by: Akhil Goyal > > > > --- > > > > devtools/libabigail.abignore | 6 +++++- > > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > > > > index 6c0b38984..654755314 100644 > > > > --- a/devtools/libabigail.abignore > > > > +++ b/devtools/libabigail.abignore > > > > @@ -19,4 +19,8 @@ > > > > ; Ignore fields inserted in cacheline boundary of rte_cryptodev > > > > [suppress_type] > > > > name = rte_cryptodev > > > > - has_data_member_inserted_between = {offset_after(attached), end} > > > > \ No newline at end of file > > > > + has_data_member_inserted_between = {offset_after(attached), end} > > > > + > > > > +; Ignore changes in reserved fields > > > > +[suppress_variable] > > > > + name_regexp = reserved > > > Mm, this rule is a bit scary, as it matches anything with "reserved" in it. > > > > Why do you feel it is scary? Reserved is something which may change at any time > > Just like experimental. Hence creating a generic exception rule for it make sense > > And it is done intentionally in this patch. > > The reserved regexp on the name of a variable / struct field is too lax. > Anything could be named with reserved in it. > If we have clear patterns, they must be preferred, like (untested) > name_regexp = ^reserved_(64|ptr)s$ > +1 to have a clear name. I would suggest using a "__reserved" prefix, since no real field name should ever start with that prefix.