On Thu, Apr 2, 2020 at 2:37 PM Ananyev, Konstantin <konstantin.anan...@intel.com> wrote: > > 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 errors: > $ 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 = enum > name = rte_crypto_asym_xform_type > changed_enumerators = RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > +; Ignore updates of ring prod/cons > +[suppress_type] > + type_kind = struct > + name = rte_ring > + has_data_members_inserted_at = offsetof(prod) > + has_data_members_inserted_at = offsetof(cons)
Hum, I could not find offsetof() in the manual but I did find offset_of(). But anyway, I understand this has_data_members_inserted_at is a way to select structs. Not a way to filter out changes that touches fields offsets inside the rte_ring structure. So you might as well simplify the rule and suppress the whole rte_ring struct changes. I suspect this is what is happening here: abidiff did not complain about the offsetof vs offset_of thing, so the has_data_members_inserted_at criterias may have been ignored. -- David Marchand
