From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 346DAA057B; Thu, 2 Apr 2020 15:13:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90A472BCE; Thu, 2 Apr 2020 15:13:47 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 467B32B8B for ; Thu, 2 Apr 2020 15:13:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585833225; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JaqDAaJb993uyd/VWnXu77sagEvc+3972pPaKi3Z8ms=; b=dW77m54cRbQxssH9a25B/scP2A3+1pSN9qjF9OZZWVcf8dGcMoMs/f5DH7M/61rp+G/5QM NlBLckrRr3eszvpobIefI3em6zkj7O1DtdBLdnzMe9hX62bQ0XaH7Cy1Gu6bFj/zBHuLp6 gFcsrn1875JdbRW+0nMufvGTEdBiZCU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-tmODZrgiMiyD29gSyTRjNA-1; Thu, 02 Apr 2020 09:13:40 -0400 X-MC-Unique: tmODZrgiMiyD29gSyTRjNA-1 Received: by mail-wm1-f70.google.com with SMTP id l13so1383374wme.7 for ; Thu, 02 Apr 2020 06:13:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=8qaisGdNmg1YkaLU+RqN395aWNyXmUxnz0S4+O3ShVE=; b=KD98a8FBFNnkF/3ldURhCgJH4dquKknnv7IGEn3xehGT04CiamTIJboUMrdwpF7f9i 19crWlNBJUcovC+N5+MTKq2Bc9SXmfDMElqLdbZICvH4E3Awc/renFDMVELTovF//u/T d5t44/MeKpWPCyX+ReClF/nniQVyNeeqjirqaSZhThHlW1A9ba+hIifGLY+VgTOH7sz0 /zbIF7RXuBBTWMrqgKMQqCrYRWAaJ7gEl6jQQapBBvUb///YtJGAqNg2nGWHSQsqnPv9 BhPbGvW56QT+pdODoXIXTxgn+zt7T18FBO1PN097k/3xuvf9cSTLIcN3DcpsIUS4Epe6 U9XA== X-Gm-Message-State: AGi0PuZs5FfXn7J8WnVOR59i4OfPBhNaNXwUsJb5MlWcTy5Fj+r7a9Az pnB+NyTB4eLQGvlvaOES02EmOVUaXjmCJfOmtaOPzwy2hISyzRn6kCYX6WxmEDX2U7ZGaPHf9BB ZI4U= X-Received: by 2002:a5d:4111:: with SMTP id l17mr3713965wrp.271.1585833219307; Thu, 02 Apr 2020 06:13:39 -0700 (PDT) X-Google-Smtp-Source: APiQypKxq2viAcZvMgyPoUhK+NW2Hs98ZjOiS7QIpzNOi/C7AwvdSBo5B5v68awpJo7HSFuYmzxe0A== X-Received: by 2002:a5d:4111:: with SMTP id l17mr3713926wrp.271.1585833218877; Thu, 02 Apr 2020 06:13:38 -0700 (PDT) Received: from localhost (91-166-131-130.subs.proxad.net. [91.166.131.130]) by smtp.gmail.com with ESMTPSA id y7sm7617911wrq.54.2020.04.02.06.13.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 06:13:38 -0700 (PDT) From: Dodji Seketeli X-Google-Original-From: Dodji Seketeli Received: by localhost (Postfix, from userid 1000) id 33BD0581890; Thu, 2 Apr 2020 15:13:36 +0200 (CEST) To: "Ananyev\, Konstantin" Cc: David Marchand , "thomas\@monjalon.net" , "nhorman\@tuxdriver.com" , "honnappa.nagarahalli\@arm.com" , "dev\@dpdk.org" , "Richardson\, Bruce" , "Yigit\, Ferruh" , Dodji Seketeli , "Laatz\, Kevin" Organization: Red Hat / France References: X-Operating-System: Fedora 33 X-URL: http://www.redhat.com Date: Thu, 02 Apr 2020 15:13:36 +0200 In-Reply-To: (Konstantin Ananyev's message of "Thu, 2 Apr 2020 12:36:58 +0000") Message-ID: <87imiiowsf.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] /validate-abi.sh complains [PATCH v1 3/8] ring: introduce RTS ring mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hello, "Ananyev, Konstantin" writes: > Hi David, > >> > Have a question regarding validate-abi.sh. >> > It complains on the following changes with that patch: >> > >> > @@ -111,11 +129,21 @@ struct rte_ring { >> > char pad0 __rte_cache_aligned; /**< empty cache line */ >> > >> > /** Ring producer status. */ >> > - struct rte_ring_headtail prod __rte_cache_aligned; >> > + RTE_STD_C11 >> > + union { >> > + struct rte_ring_headtail prod; >> > + struct rte_ring_rts_headtail rts_prod; >> > + } __rte_cache_aligned; >> > + >> > char pad1 __rte_cache_aligned; /**< empty cache line */ >> > >> > /** Ring consumer status. */ >> > - struct rte_ring_headtail cons __rte_cache_aligned; >> > + RTE_STD_C11 >> > + union { >> > + struct rte_ring_headtail cons; >> > + struct rte_ring_rts_headtail rts_cons; >> > + } __rte_cache_aligned; >> > + [...] >> It reported a warning on those fields: >> https://travis-ci.com/github/ovsrobot/dpdk/jobs/310689008#L2380 >> I understand this as a false positive too. >>=20 >> It seems similar to the bz I opened about fields moved to anonymous >> constructs: https://sourceware.org/bugzilla/show_bug.cgi?id=3D25661 > > Yes, looks the same. > > >> Cc: Dodji. >>=20 >>=20 >> For the time being, you can waive this by adding a rule in >> devtools/libabigail.abignore. > > Ok, so what is the procedure here? > Should I submit changes to devtools/libabigail.abignore together with the > patch that introduced the problem? > BTW, I used the following changes in libabigail.abignore to supress error= s: > $ git diff devtools/libabigail.abignore > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index a59df8f13..032479b9f 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -11,3 +11,9 @@ > type_kind =3D enum > name =3D rte_crypto_asym_xform_type > changed_enumerators =3D RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > +; Ignore updates of ring prod/cons > +[suppress_type] > + type_kind =3D struct > + name =3D rte_ring > + has_data_members_inserted_at =3D offsetof(prod) > + has_data_members_inserted_at =3D offsetof(cons) > > Do you know, is there a better (more fine-grained) approach? I think what you did is correct. I am teaching the tool to recognize this kind of change construct and avoid emitting a false positive. So that you can drop these kind of suppression specification. Sorry for the inconvenience. Cheers, --=20 =09=09Dodji