From: David Marchand <david.marchand@redhat.com>
To: Dodji Seketeli <dodji@redhat.com>
Cc: Phil Yang <Phil.Yang@arm.com>,
Olivier Matz <olivier.matz@6wind.com>,
Ray Kinsella <mdr@ashroe.eu>, dev <dev@dpdk.org>,
Stephen Hemminger <stephen@networkplumber.org>,
David Christensen <drc@linux.vnet.ibm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Ruifeng Wang <Ruifeng.Wang@arm.com>, nd <nd@arm.com>,
Aaron Conole <aconole@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/2] mbuf: use C11 atomic built-ins for refcnt operations
Date: Thu, 16 Jul 2020 21:11:59 +0200 [thread overview]
Message-ID: <CAJFAV8w_X1DEf_QE5pm6WP7m9BZiCDH36b9C3x0deGy=6fDU9A@mail.gmail.com> (raw)
In-Reply-To: <87h7u7k344.fsf@redhat.com>
On Thu, Jul 16, 2020 at 3:21 PM Dodji Seketeli <dodji@redhat.com> wrote:
> Just for the sake of precision, I'd like to say that in the coming 1.8
> version of libabigail, this change won't be reported by the tooling as a
> problem anymore. This is thanks to David filing the feature request
> https://sourceware.org/bugzilla/show_bug.cgi?id=25661 a while ago.
>
> Until then, I understand that the current tooling needs to work with
> libabigail 1.6.
That's what we have in the CI with a 1.6 libabigail compiled in Ubuntu 18.04.
I tested 20.04 in Travis (I can send a patch later), but it still has
a 1.6 version.
We will have to live with a "not that recent" version for some time.
>
> So maybe a more specific suppression rule (that you could still remove
> for the 20.11 stable branch) could look like:
>
> [suppress_type]
> name = rte_mbuf_ext_shared_info
> has_data_member_inserted_between = {offset_of(refcnt_atomic), offset_of(refcnt_atomic)}
>
>
> It's a "hack" that will only suppress change reports on the
> rte_mbuf_ext_shared_info type if:
>
> 1/ it it has a data member inserted at the
> offset of its data member 'refcnt_atomic',
>
> AND
>
> 2/ the size of rte_mbuf_ext_shared_info doesn't change.
>
>
> There are cases where this won't work, though. But it might work for
> this case. If it does, then great. I think it'd be a better solution
> than a blanket suppression of all the changes on the type.
Nice, thanks Dodji.
--
David Marchand
next prev parent reply other threads:[~2020-07-16 19:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 10:26 [dpdk-dev] [PATCH] mbuf: use c11 atomics " Phil Yang
2020-07-03 15:38 ` David Marchand
2020-07-06 8:03 ` Phil Yang
2020-07-07 10:10 ` [dpdk-dev] [PATCH v2] mbuf: use C11 " Phil Yang
2020-07-07 17:13 ` Stephen Hemminger
2020-07-08 4:48 ` Phil Yang
2020-07-08 11:43 ` Olivier Matz
2020-07-09 9:52 ` Phil Yang
2020-07-08 5:11 ` Phil Yang
2020-07-08 11:44 ` Olivier Matz
2020-07-09 10:00 ` Phil Yang
2020-07-09 10:10 ` [dpdk-dev] [PATCH v3] mbuf: use C11 atomic built-ins " Phil Yang
2020-07-09 11:03 ` Olivier Matz
2020-07-09 13:00 ` Phil Yang
2020-07-09 13:31 ` Honnappa Nagarahalli
2020-07-09 14:10 ` Phil Yang
2020-07-09 15:58 ` [dpdk-dev] [PATCH v4 1/2] " Phil Yang
2020-07-09 15:58 ` [dpdk-dev] [PATCH v4 2/2] doc: announce deprecation of refcnt atomic member Phil Yang
2020-07-10 2:55 ` Ruifeng Wang
2020-07-13 15:54 ` Phil Yang
2020-07-14 10:41 ` Ananyev, Konstantin
2020-07-15 12:29 ` [dpdk-dev] [PATCH v4 1/2] mbuf: use C11 atomic built-ins for refcnt operations David Marchand
2020-07-15 12:49 ` Aaron Conole
2020-07-15 16:29 ` Phil Yang
2020-07-16 4:16 ` Phil Yang
2020-07-16 11:30 ` David Marchand
2020-07-16 13:20 ` Dodji Seketeli
2020-07-16 19:11 ` David Marchand [this message]
2020-07-17 4:41 ` Phil Yang
2020-07-16 11:32 ` Olivier Matz
2020-07-17 4:36 ` [dpdk-dev] [PATCH v5 1/2] mbuf: use C11 atomic builtins " Phil Yang
2020-07-17 4:36 ` [dpdk-dev] [PATCH v5 2/2] doc: announce deprecation of refcnt atomic member Phil Yang
2020-07-17 11:45 ` Olivier Matz
2020-07-17 14:32 ` David Marchand
2020-07-17 14:35 ` David Marchand
2020-07-17 16:06 ` Ananyev, Konstantin
2020-07-17 16:20 ` Bruce Richardson
2020-07-21 8:35 ` David Marchand
2020-07-21 8:48 ` Ananyev, Konstantin
2020-07-21 8:37 ` [dpdk-dev] [PATCH v5 1/2] mbuf: use C11 atomic builtins for refcnt operations David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJFAV8w_X1DEf_QE5pm6WP7m9BZiCDH36b9C3x0deGy=6fDU9A@mail.gmail.com' \
--to=david.marchand@redhat.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Phil.Yang@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=dodji@redhat.com \
--cc=drc@linux.vnet.ibm.com \
--cc=mdr@ashroe.eu \
--cc=nd@arm.com \
--cc=olivier.matz@6wind.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).