> -----Original Message----- > From: Yigit, Ferruh <ferruh.yi...@intel.com> > Sent: Friday, January 31, 2020 9:07 AM > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Thomas Monjalon > <tho...@monjalon.net>; Anoob Joseph > <ano...@marvell.com>; akhil.go...@nxp.com; Trahe, Fiona > <fiona.tr...@intel.com> > Cc: dev@dpdk.org; David Marchand <david.march...@redhat.com>; Richardson, > Bruce <bruce.richard...@intel.com>; > nhor...@tuxdriver.com; Mcnamara, John <john.mcnam...@intel.com>; Kusztal, > ArkadiuszX <arkadiuszx.kusz...@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-boun...@dpdk.org> On Behalf Of Thomas Monjalon > >> Sent: Thursday, January 30, 2020 4:00 PM > >> To: Anoob Joseph <ano...@marvell.com>; akhil.go...@nxp.com; Trahe, Fiona > >> <fiona.tr...@intel.com> > >> Cc: dev@dpdk.org; David Marchand <david.march...@redhat.com>; Richardson, > >> Bruce <bruce.richard...@intel.com>; > >> nhor...@tuxdriver.com; Mcnamara, John <john.mcnam...@intel.com>; Trahe, > >> Fiona <fiona.tr...@intel.com>; Kusztal, ArkadiuszX > >> <arkadiuszx.kusz...@intel.com>; Yigit, Ferruh <ferruh.yi...@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.)?
