Re: [dpdk-dev] [dpdklab] Re: [PATCH v5 1/5] devargs: unify scratch buffer storage

[Thomas Monjalon <thomas@monjalon.net>]

16/04/2021 14:43, Lincoln Lavoie:
> All of the UNH ABI testing is moving info containers, so it can be run on
> top of each OS, alongside the other compile and unit testing. This is
> actually ready now, but hasn't been pushed live this week, because of the
> backlog in the system because of the DTS failure.  The additional compile
> jobs are already online now, it's just ABI that hasn't been pushed live.
> 
> This means the current ABI (what is reporting right now) is running on
> 18.04 for x86 and 20.04 for aarch64.  The aarch64 one will continue
> forward, because we're not going to moving to emulated environments for
> testing on that architecture.
> 
> This has two implications, first, the scripts for running ABI (and the
> other tests) become part of the container definition, and at the last
> meeting we talked about moving those definitions into the dpdk-ci repo,
> which I think makes sense.  Second, there isn't an operating system to
> "maintain" since it's what's inside the container images, which are
> periodically rebuilt, but pretty much treated as ephemeral.  Assuming the
> container bases / distros have the updated libabigail version packaged with
> them.

No, the version packaged in the OS is not recent enough.
Please check what is done in Travis and GitHub CI
in the shell function install_libabigail():
https://git.dpdk.org/dpdk/tree/.ci/linux-build.sh#n22


> On Fri, Apr 16, 2021 at 8:32 AM Aaron Conole <aconole@redhat.com> wrote:
> > David Marchand <david.marchand@redhat.com> writes:
> >
> > > On Tue, Apr 13, 2021 at 5:15 AM Xueming Li <xuemingl@nvidia.com> wrote:
> > >> diff --git a/lib/librte_eal/include/rte_devargs.h
> > b/lib/librte_eal/include/rte_devargs.h
> > >> index 296f19324f..134b44a887 100644
> > >> --- a/lib/librte_eal/include/rte_devargs.h
> > >> +++ b/lib/librte_eal/include/rte_devargs.h
> > >> @@ -60,16 +60,16 @@ struct rte_devargs {
> > >>         /** Name of the device. */
> > >>         char name[RTE_DEV_NAME_MAX_LEN];
> > >>         RTE_STD_C11
> > >> -       union {
> > >> -       /** Arguments string as given by user or "" for no argument. */
> > >> -               char *args;
> > >> +       union { /**< driver-related part of device string. */
> > >> +               const char *args; /**< legacy name. */
> > >>                 const char *drv_str;
> > >>         };
> > >>         struct rte_bus *bus; /**< bus handle. */
> > >>         struct rte_class *cls; /**< class handle. */
> > >>         const char *bus_str; /**< bus-related part of device string. */
> > >>         const char *cls_str; /**< class-related part of device string.
> > */
> > >> -       const char *data; /**< Device string storage. */
> > >> +       char *data;
> > >> +       /**< Raw string including bus, class and driver arguments. */
> > >>  };
> > >>
> > >>  /**
> > >
> > > - Flagging this patch for info and its impact on UNH jobs.
> > >
> > > This change is fine, but older libabigail versions could not deal with
> > > such changes (anonymous union, changes of const fields).
> > > This results in an ABI check failure in the UNH x86 job on Ubuntu
> > > 18.04 (and for some people not using recent libabigail).
> > > I can see the ARM job passes fine, so I suppose it is using a more
> > > recent libabigail (running Ubuntu 20.04 maybe?).
> > >
> > > We either need to disable this x86 job or update its libabigail
> > > package (maybe aligning with what we have for public CI which is
> > > libabigail 1.8 manually compiled).
> > >
> > >
> > > - For the longer term, what do you think of using/extending the .ci/
> > > scripts for use by UNH jobs?
> >
> > I think it would be great if we had some of the scripts shared as a
> > common resource.  That would also help us to look at fixes / changes
> > when needed.
> >
> >
> 
>