> > > > 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().
Yep, typo from me. > > 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. Seems so. > So you might as well simplify the rule and suppress the whole rte_ring > struct changes. Ok. > 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. > Konstantin
