[v2] abi: change references to abi 20.0.1 to abi v21

  Change references to abi 20.0.1 to use abi v21, add myself as the map
file maintainer to more closely monitor future abi changes. Add
suppressions that were missed on changes to librte_lpm.

Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
 MAINTAINERS                                         |  2 ++
 devtools/libabigail.abignore                        | 13 ++++++++++++-
 drivers/common/iavf/rte_common_iavf_version.map     |  2 +-
 drivers/common/mlx5/rte_common_mlx5_version.map     |  2 +-
 .../octeontx2/rte_common_octeontx2_version.map      |  2 +-
 drivers/net/ionic/rte_pmd_ionic_version.map         |  2 +-
 .../rte_rawdev_octeontx2_ep_version.map             |  2 +-
 drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map     |  2 +-
 lib/librte_meter/rte_meter_version.map              |  2 +-
 9 files changed, 21 insertions(+), 8 deletions(-)
  

23/04/2020 08:41, Ray Kinsella:
> Change references to abi 20.0.1 to use abi v21, add myself as the map
> file maintainer to more closely monitor future abi changes. Add
> suppressions that were missed on changes to librte_lpm.
> 
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>

Please could you add a reference to the doc chapter stating this rule,
in the commit log? Thanks
  

On Thu, Apr 23, 2020 at 8:48 AM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> Change references to abi 20.0.1 to use abi v21, add myself as the map
> file maintainer to more closely monitor future abi changes. Add
> suppressions that were missed on changes to librte_lpm.

About the lpm change below, this might be because you are using an old
version of libabigail.
I think the change went in:
$ git describe --contains 215b7eb4
libabigail-1.4~8

I use either libabigail 1.7 or the current master (when testing Dodji
enhancements).


> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index cd86d89ca..20c821cee 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -2,7 +2,6 @@
>          symbol_version = EXPERIMENTAL
>  [suppress_variable]
>          symbol_version = EXPERIMENTAL
> -
>  ; Explicit ignore for driver-only ABI
>  [suppress_type]
>          name = rte_cryptodev_ops
> @@ -18,3 +17,15 @@
>  [suppress_type]
>          type_kind = struct
>          name = rte_event_ring
> +; Explicit ignore ABI 20.0.1
> +[suppress_function]
> +        symbol_version = DPDK_20.0.1
> +[suppress_variable]
> +        symbol_version = DPDK_20.0.1
> +; Explicit ignore of const lpm6_lookup change
> +[suppress_function]
> +        name = rte_lpm6_delete
> +        parameter = '1 uint8_t*
> +[suppress_function]
> +        name = rte_lpm6_is_rule_present
> +        parameter = '1 uint8_t*
  

ah ok, the particular system I made the change on was Ubuntu 18.04.2.
which is libabigail 1.2.0.

Given we still support v19.11 on Ubuntu 18.04.2.
I think it's worthwhile keeping the suppression until v20.11?

Ray K

On 24/04/2020 15:10, David Marchand wrote:
> On Thu, Apr 23, 2020 at 8:48 AM Ray Kinsella <mdr@ashroe.eu> wrote:
>>
>> Change references to abi 20.0.1 to use abi v21, add myself as the map
>> file maintainer to more closely monitor future abi changes. Add
>> suppressions that were missed on changes to librte_lpm.
> 
> About the lpm change below, this might be because you are using an old
> version of libabigail.
> I think the change went in:
> $ git describe --contains 215b7eb4
> libabigail-1.4~8
> 
> I use either libabigail 1.7 or the current master (when testing Dodji
> enhancements).
> 
> 
>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
>> index cd86d89ca..20c821cee 100644
>> --- a/devtools/libabigail.abignore
>> +++ b/devtools/libabigail.abignore
>> @@ -2,7 +2,6 @@
>>          symbol_version = EXPERIMENTAL
>>  [suppress_variable]
>>          symbol_version = EXPERIMENTAL
>> -
>>  ; Explicit ignore for driver-only ABI
>>  [suppress_type]
>>          name = rte_cryptodev_ops
>> @@ -18,3 +17,15 @@
>>  [suppress_type]
>>          type_kind = struct
>>          name = rte_event_ring
>> +; Explicit ignore ABI 20.0.1
>> +[suppress_function]
>> +        symbol_version = DPDK_20.0.1
>> +[suppress_variable]
>> +        symbol_version = DPDK_20.0.1
>> +; Explicit ignore of const lpm6_lookup change
>> +[suppress_function]
>> +        name = rte_lpm6_delete
>> +        parameter = '1 uint8_t*
>> +[suppress_function]
>> +        name = rte_lpm6_is_rule_present
>> +        parameter = '1 uint8_t*
> 
>
  

On Fri, Apr 24, 2020 at 4:50 PM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> ah ok, the particular system I made the change on was Ubuntu 18.04.2.
> which is libabigail 1.2.0.
>
> Given we still support v19.11 on Ubuntu 18.04.2.
> I think it's worthwhile keeping the suppression until v20.11?

1.2 is fairly old and does not seem maintained by Ubuntu (asked for
backport, and got ignored so far).
https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607

Dodji told me that there were new checks added in newer sersions.
I also fear that supporting an old libabigail version will force us to
add a lot of other rules.

In Travis, we currently use libabigail 1.6 (mainly because I did not
update to 1.7 when it was released).
  

Hello,

Ray Kinsella <mdr@ashroe.eu> writes:

> ah ok, the particular system I made the change on was Ubuntu 18.04.2.
> which is libabigail 1.2.0.

Whoah, 1.2 is super old.

In my opinion, one of the hallmarks of static analysis tools (and
libabigail is just a static analysis framework) is to be able to
recognize patterns used by developers, as much as we can.

Because we can't really do that at once, we try to add recognition of
new patterns (of ABI changes) at every single release.  Furthermore,
there are some change patterns that ought to be recognized and
categorized as harmless, whereas some others out to be categorized as
harmful.  That categorization is also the result of input coming from
users as you, fine fellows.

All this to say that with every new version, the number of new supported
features and bug fixes is potentially big.

To alleviate that, some distributors update libabigail even in their old
stable distros, because the value of having an up to date version there
outweighs the potential drawbacks.

> Given we still support v19.11 on Ubuntu 18.04.2.

So maybe that's a discussion worth having with the maintainer of the
Ubuntu package of Libabigail?

> I think it's worthwhile keeping the suppression until v20.11?

[...]

David Marchand <david.marchand@redhat.com> writes:

> In Travis, we currently use libabigail 1.6 (mainly because I did not
> update to 1.7 when it was released).

Right, that's probably another way to stay up to date independently from
the underlying distribution.

I hope this helps,

Cheers,
  

On 29/04/2020 13:19, Dodji Seketeli wrote:
> Hello,
> 
> Ray Kinsella <mdr@ashroe.eu> writes:
> 
>> ah ok, the particular system I made the change on was Ubuntu 18.04.2.
>> which is libabigail 1.2.0.
> 
> Whoah, 1.2 is super old.

I have a huge clunking raid'ed "build" server,
that I am pretty conservative about upgrading on v18.04.2 :-)

> In my opinion, one of the hallmarks of static analysis tools (and
> libabigail is just a static analysis framework) is to be able to
> recognize patterns used by developers, as much as we can.
> 
> Because we can't really do that at once, we try to add recognition of
> new patterns (of ABI changes) at every single release.  Furthermore,
> there are some change patterns that ought to be recognized and
> categorized as harmless, whereas some others out to be categorized as
> harmful.  That categorization is also the result of input coming from
> users as you, fine fellows.
> 
> All this to say that with every new version, the number of new supported
> features and bug fixes is potentially big.
> 
> To alleviate that, some distributors update libabigail even in their old
> stable distros, because the value of having an up to date version there
> outweighs the potential drawbacks.

Well it falls into the same category of problems of upgrading compilers.
User's typically build their software build reliably on a given distro version.
(or number of versions). 

If the maintainer upgrades compilers between distro versions, it introduces new 
warnings and errors, and all hell will generally break loose, when the user least expects it. 
They typically expect that mayhem when upgrading to new distro versions. 
Even tools like GNU indent can cause enormous problems. 

I would imagine that most maintainers would be pretty conservative about making
such changes. 

> 
>> Given we still support v19.11 on Ubuntu 18.04.2.
> 
> So maybe that's a discussion worth having with the maintainer of the
> Ubuntu package of Libabigail?

yes - I think it would be an interesting discussion alright.
I imagine the response might be inline with my understanding above.
Let's find out - as we can expect v18.04 to be around for at least another
two years I guess.

Another common way to handle this, is to be really explicit about what 
OS distros DPDK formally supports building on, which will then imply 
we support a small handful of versions of libabigail. 

We then simply say we don't support 18.04 anymore - FD.io VPP are planning 
this formal switch at the moment. 

> 
>> I think it's worthwhile keeping the suppression until v20.11?
> 
> [...]
> 
> David Marchand <david.marchand@redhat.com> writes:
> 
>> In Travis, we currently use libabigail 1.6 (mainly because I did not
>> update to 1.7 when it was released).
> 
> Right, that's probably another way to stay up to date independently from
> the underlying distribution.

You typically don't want to encourage this, you end up with some people
on a newer version, some people on an old version and never upgrading. 

Then you never end up with a consistent view of what mitigations are actually required.
Solving issues, becomes like a game of whack-a-mole. 

> 
> I hope this helps,

It does, greatly thanks. 

> 
> Cheers,
>