[dpdk-dev] [PATCH v3 01/12] common/dpaax: move internal symbols into INTERNAL section

[David Marchand]

On Thu, May 14, 2020 at 1:10 PM Ray Kinsella <mdr at ashroe.eu> wrote:
>
>
>
> On 14/05/2020 12:06, Hemant Agrawal (OSS) wrote:
> >
> >> On 14/05/2020 10:53, Hemant Agrawal (OSS) wrote:
> >>> [Hemant] Thanks it worked  for me. It is not showing any error for the
> >> changes in this patchset.
> >>
> >> I tested it also - and it didn't show an error either, which confused me. As you
> >> are dropping a whole bunch of symbols from DPDK v20, it _should_ baulk at
> >> this.
> >>
> >> Need to dig a bit deeper on this.
> >
> > [Hemant] I have also made change in  libabigail.abignore. That should be the reason for no complains?
>
> yes ... I discovered that since.
> are we 100% certain that no end user application would  ever have used these symbol?
>
> [suppress_variable]
>          name = rte_crypto_aead_algorithm_strings
> +; Ignore moving DPAAx stable functions to INTERNAL tag
> +[suppress_file]
> +       file_name_regexp = ^librte_common_dpaax\.
> +[suppress_file]
> +       file_name_regexp = ^librte_mempool_dpaa\.
> +[suppress_file]
> +       file_name_regexp = ^librte_bus_fslmc\.
> +[suppress_file]
> +       file_name_regexp = ^librte_bus_dpaa\.
> +[suppress_file]
> +       file_name_regexp = ^librte_pmd_dpaa\.

Ignoring the whole dpaa net driver is wrong as the symbol
rte_pmd_dpaa_set_tx_loopback is marked stable.
This is used by applications, like testpmd:
app/test-pmd/cmdline.c:         ret =
rte_pmd_dpaa_set_tx_loopback(res->port_id, is_on);

You need a more refined filter for this.
Public APIs are prefixed with rte_ so maybe whitelisting ^dpaa_
variables/functions?


-- 
David Marchand