You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] New ABI version dedicated for debug interface #2374
Is your feature request related to a problem? Please describe.
The sof-logger and potentially other debug API clients perform ABI compatibility check using the single FW ABI version. The same one is used by the primary FW client which is the kernel driver. If there is a change made to the debug API, the main ABI has to be updated to protect integrity of the debug tools while such a change may not affect the kernel driver at all.
Describe the solution you'd like
Introduce new debug ABI version and bump only that one if the main ABI is not affected. Recompilation and installation of the new driver every time the tunneled debug protocol is upgraded could be avoided.
Describe alternatives you've considered
Stay with a single ABI version and recompile & redeploy all components at once to keep ABI versioning simpler.
I am for maintaining separate ABIs. I believe in the future a third ABI will also be required for modules (I doubt my ability to just link them in directly, because the rimage format doesn't hold all required information to just link like in the ELF style) so having separate, individually updateable ABIs is what will happen anyway.
When you change the kernel interface ABI, the kernel driver will have to update to support the change. When you change the debug ABI (logger etc) you update the tools.
Distros really don't like keeping kernel and userspace in sync when it comes to updates so the separation is a good idea in my view. @plbossart ?
well it depends on the intent.
for the kernel, we are always backwards-compatible with older firmware.
But in the case of debug tools, what's the story? do we assume that sof-logger and others are all matching the firmware version?
@plbossart Yes, there is a consistency check in the sof-logger. I'd like to keep it since I am going to change the log entry format and that protection of dsp<->dbg-client (sof-logger in this case) API use integrity is quite useful. However it is based on the only main ABI version atm.
Activity
mmaka1 commentedon Feb 12, 2020
@plbossart @lgirdwood @dbaluta @paulstelian97 Please share your opinion.
paulstelian97 commentedon Feb 12, 2020
I am for maintaining separate ABIs. I believe in the future a third ABI will also be required for modules (I doubt my ability to just link them in directly, because the rimage format doesn't hold all required information to just link like in the ELF style) so having separate, individually updateable ABIs is what will happen anyway.
When you change the kernel interface ABI, the kernel driver will have to update to support the change. When you change the debug ABI (logger etc) you update the tools.
Distros really don't like keeping kernel and userspace in sync when it comes to updates so the separation is a good idea in my view. @plbossart ?
plbossart commentedon Feb 12, 2020
well it depends on the intent.
for the kernel, we are always backwards-compatible with older firmware.
But in the case of debug tools, what's the story? do we assume that sof-logger and others are all matching the firmware version?
mmaka1 commentedon Feb 12, 2020
@plbossart Yes, there is a consistency check in the sof-logger. I'd like to keep it since I am going to change the log entry format and that protection of dsp<->dbg-client (sof-logger in this case) API use integrity is quite useful. However it is based on the only main ABI version atm.
tlauda commentedon Mar 12, 2020
@mmaka1 To be closed?