On Thu, Jul 16, 2020 at 3:21 PM Dodji Seketeli <do...@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
