Thomas Monjalon <tho...@monjalon.net> writes:
> 15/02/2022 14:55, Ray Kinsella: >> Ray Kinsella <m...@ashroe.eu> writes: >> > Thomas Monjalon <tho...@monjalon.net> writes: >> >> 14/02/2022 17:06, Ray Kinsella: >> >>> Thomas Monjalon <tho...@monjalon.net> writes: >> >>> > 14/02/2022 11:16, Ray Kinsella: >> >>> >> Ray Kinsella <m...@ashroe.eu> writes: >> >>> >> > Thomas Monjalon <tho...@monjalon.net> writes: >> >>> >> >> We never know how this enum will be used by the application. >> >>> >> >> The max value may be used for the size of an event array. >> >>> >> >> It looks a real ABI issue unfortunately. >> >>> >> > >> >>> >> > Right - but we only really care about it when an array size based >> >>> >> > on MAX >> >>> >> > is likely to be passed to DPDK, which doesn't apply in this case. >> >>> > >> >>> > I don't completely agree. >> >>> > A developer may assume an event will never exceed MAX value. >> >>> > However, after an upgrade of DPDK without app rebuild, >> >>> > a higher event value may be received in the app, >> >>> > breaking the assumption. >> >>> > Should we consider this case as an ABI breakage? >> >>> >> >>> Nope - I think we should explicitly exclude MAX values from any >> >>> ABI guarantee, as being able to change them is key to our be able to >> >>> evolve DPDK while maintaining ABI stability. >> >> >> >> Or we can simply remove the MAX values so there is no confusion. >> >> >> >>> Consider what it means applying the ABI policy to a MAX value, you are >> >>> in effect saying that that no value can be added to this enumeration >> >>> until the next ABI version, for me this is very restrictive without a >> >>> solid reason. >> >> >> >> I agree it is too much restrictive, that's why I am advocating >> >> for their removal. >> > >> > I think that would be simplest yes - may require some rework of the >> > sample code though. I will take a look at it. >> >> Thinking about this some more - we can't remove the MAX values between >> now the next stable ABI. So we may need a short term plan, and long term >> plan. >> >> Long term, I agree we look at every _MAX enumeration value and ask do we >> need it. >> >> Short term (until the next ABI), we still need to answer the question do >> we allow people to change _MAX values? > > There's a problem of incentive. > We already said in the past that we should remove the _MAX values, > but it doesn't happen because our time on this planet is limited. > I think it would work if the developers have a special interest in such work. > And guess what? Here there is a special interest to remove this one. > If we are at the negotiation table, we could imagine a short-term exception > if the long-term patch is available and reviewed. :-) ... I like that plan. -- Regards, Ray K
