On 23/04/2021 12:39, Gaëtan Rivet wrote:
> On Fri, Apr 23, 2021, at 13:06, Kinsella, Ray wrote:
>>
>>
>> On 14/04/2021 20:49, Thomas Monjalon wrote:
>>> 13/04/2021 05:14, Xueming Li:
>>>> Xueming Li (5):
>>>> devargs: unify scratch buffer storage
>>>> devargs: fix memory leak on parsing error
>>>> kvargs: add get by key function
>>>> bus: add device arguments name parsing API
>>>> devargs: parse global device syntax
>>>
>>> The patch 4 adds a new callback in rte_bus.
>>> I thought about it during the whole day and I don't see any good way
>>> to merge it without breaking the ABI compatibility.
>>>
>>> Only first 3 patches are applied for now, thanks.
>>>
>>
>> I took a look, I don't immediately see the concern.
>>
>> The new entry is at the end of the memory structure.
>> The call back is internal and hidden behind the symbol
>> rte_devargs_layers_parse.
>>
>> So will only be trigger by a rte_devargs_layers_parse of the same
>> version of DPDK that introduce the new callback.
>>
>> Should be fine?
>>
>
> It might have been an issue IMO with a structure exposed as an array, i.e.
> rte_eth_devices[].
> But I thought this kind of ABI break was the kind that would be accepted
> between two LTS.
Very much depends on how it is done.
New fields are ok in some circumstances, at first glance I thought one is ok.
> The only potential risk is in using a new version librte_eal.so with an older
> librte_bus_xxx.so
We don't account for or consider that, that would be an irrational environmnet.
> But I think it is fair to expect installations to be internally consistent.
>
> Maybe we could have a runtime warning when loading mismatched versions
Nope - that would be insanely complex.
> (if there isn't one already) -- each librte_*.so could have an internal
> version stamp and alignment could
> be checked through a constructor in each lib?
>
