[dpdk-dev] [PATCH v2 4/4] add ABI checks

[Ananyev, Konstantin]

> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit at intel.com>
> Sent: Friday, January 31, 2020 9:07 AM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Thomas Monjalon <thomas at monjalon.net>; Anoob Joseph
> <anoobj at marvell.com>; akhil.goyal at nxp.com; Trahe, Fiona <fiona.trahe at intel.com>
> Cc: dev at dpdk.org; David Marchand <david.marchand at redhat.com>; Richardson, Bruce <bruce.richardson at intel.com>;
> nhorman at tuxdriver.com; Mcnamara, John <john.mcnamara at intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks
> 
> On 1/30/2020 11:49 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -----Original Message-----
> >> From: dev <dev-bounces at dpdk.org> On Behalf Of Thomas Monjalon
> >> Sent: Thursday, January 30, 2020 4:00 PM
> >> To: Anoob Joseph <anoobj at marvell.com>; akhil.goyal at nxp.com; Trahe, Fiona <fiona.trahe at intel.com>
> >> Cc: dev at dpdk.org; David Marchand <david.marchand at redhat.com>; Richardson, Bruce <bruce.richardson at intel.com>;
> >> nhorman at tuxdriver.com; Mcnamara, John <john.mcnamara at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>; Kusztal, ArkadiuszX
> >> <arkadiuszx.kusztal at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks
> >>
> >> 30/01/2020 14:06, Trahe, Fiona:
> >>> We were unaware the LIST_END change could constitute an ABI breakage, but can see how it affects the array size when picked up.
> >>> We're exploring options.
> >>>
> >>> I agree with Anoob's point that if we don't allow the LIST_END to be modified, then it means no feature can be implemented without
> ABI
> >> breakage.
> >>> Anyone  object to removing those LIST_END elements - or have a better suggestion? Would have to be in 20.11 I suppose.
> >>
> >> Yes, having max value right after the last value is ridiculous,
> >> it prevents adding any value.
> >> In 20.11, we should remove all these *_END and *_MAX from API enums
> >> and replace them with a separate #define with reasonnable maximums.
> >>
> >
> > I think we'd better avoid public structs that have array of _MAX elems in them.
> >
> 
> That should fix, but we need to wait for 20.11 for the change, and what should
> be the new array size?

Make it dynamic whenever possible?
Make Input/output args to provide both pointer and size,
or use some predefined value for terminating element (NULL, -1, etc.)?