> > > > These sorts of changes are the type that we could collectively waive in > > terms of > > ABI checking, as they should be ok, but the errors from libabigail should be > > taken as an indicator that this API could be rewritten (for example by > > removing > > the abi entirely, and adding an API call that returns an array of instance > > name > > and ids), so that changes of the above sort arent required. > > We can spend more time on it, but I can't see for now how to escape returning > enumaration as indication of type, and this looks legitimate sage as long as > other side verifies the received value is valid in the type range. [Fiona] Regarding re-work to make the original code more robust to ABI breakage One option would be to remove LIST_END from the enum, but keep the enum and allow appending values to it. Instead of LIST_END have a static var keeping track of the MAX_NUM_AEAD_ALGOS and an API call rte_cryptodev_get_max_aead_algos() forcing an application to dynamically size any array to accommodate any new values. The API is safer I think - but there are other pitfalls with this approach - the MAX can more easily get out-of-sync with the enum. And the application still needs to safely handle values it doesn't recognise. Anyone think this is a better way?
I still think the best solution is to suppress changes to the LIST_END element.
