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

Aaron Conole aconole at redhat.com
Fri Apr 16 14:32:17 CEST 2021


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

> On Tue, Apr 13, 2021 at 5:15 AM Xueming Li <xuemingl at 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.



More information about the dev mailing list