search

thesofproject / sof

Sound Open Firmware
Other
562 stars 318 forks source link

[FEATURE] Per component ABI versioning #4892

Open cujomalainey opened 3 years ago

cujomalainey commented 3 years ago

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 commented 3 years ago

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

lgirdwood commented 3 years ago

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 commented 3 years ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.