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.
