[FEATURE] Per component ABI versioning

[cujomalainey]

Is your feature request related to a problem? Please describe.
We have a strong ABI control mechanism for the IPC ABI, but nothing equivalent exists for the underlying ABI for components byte controls such as EQ/MUX/DRC. Should an audio server such as CRAS want to start generating coefficients dynamically for a number of firmware versions it becomes quite complex to track what ABI to use where. To add to this complexity, we do not have access to logical kernel headers for core ABI version to possibly infer ABI differences in the components from.

Describe the solution you'd like
A definitive way to infer what ABI to use where and when. A possible idea is to version the components themselves and have them publish their versions through a control which can be consumed by a library to generate coefficients dynamically. Another would be version the control name.

Describe alternatives you've considered
Global versioning is not likely to work as this can be easily broken by cherry-picking to release branches, also without having some sort of ioctl or control it is much harder to access. Debugfs is discouraged.

@bzhg @johnylin76 @poloo5582 @afq984 FYI

[cujomalainey]

This bug is mostly for community discussion, Google can drive this integration if community approves.

[lgirdwood]

Adding @plbossart @juimonen @beatabaranowska since this was discussed in TSC around topology qualifiers/negotiation but this really has to be around all ingredients.
@cujomalainey fwiw this also fits into what I'm looking at for after IPC3/4, still early days but intention is to use tuples for all IPC and this could also apply to binary kcontrol config too. https://github.com/thesofproject/ipc-tuples

[cujomalainey]

@lgirdwood thanks I will read up on that this week. I still think we should consider building a lib on github which can generate blobs given a components binary revision number (for open source components). Maybe a rust project?

[kv2019i]

FYI @singalsu @ujfalusi @mwasko @lgirdwood this is still an open. At this point, one really has to add a new component (with a new UUID) if the ABI is changed. Similar constraint is for IPC4 modules.

[singalsu]

I think this would be a welcome change. To expose the version via control content would be quite simple and reliable. Control name as version would require the FW and topology to be well in sync.

[lgirdwood]

I think this needs to come after IPC4 and module adapter integration. i.e. we have a stable module API & IPC ABI to extend in this direction.