On Thu, May 14, 2020 at 1:10 PM Ray Kinsella <m...@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
