Describe the bug
Currently an IPC subset, sufficient to run SRC in DP userspace mode, is redirected to the userspace thread, while if SRC were to implement an additional method, e.g. .trigger() or .set_config_param() then it would be called directly by the IPC thread in kernel mode.
Similarly, it might be possible for modules to set up other callbacks, e.g. data blob validators, calling comp_data_blob_set_validator(). Or maybe data blob handlers like .free() can be overwritten by the module. Similarly other callback APIs (notifications, AMS,...) have to be sanitised too.
To Reproduce
Cannot be reproduced with the current "main," needs at least a modified topology. E.g. one could switch ASRC to DP mode, and ASRC implements a .trigger() method.
Reproduction Rate
100%
Expected behavior
Should be redirected to the DP thread as other struct module_interface methods.
Impact
Currently none, but will become severe once unsigned DP modules become accepted
Environment
"main"
Describe the bug
Currently an IPC subset, sufficient to run SRC in DP userspace mode, is redirected to the userspace thread, while if SRC were to implement an additional method, e.g.
.trigger()or.set_config_param()then it would be called directly by the IPC thread in kernel mode.Similarly, it might be possible for modules to set up other callbacks, e.g. data blob validators, calling
comp_data_blob_set_validator(). Or maybe data blob handlers like.free()can be overwritten by the module. Similarly other callback APIs (notifications, AMS,...) have to be sanitised too.To Reproduce
Cannot be reproduced with the current "main," needs at least a modified topology. E.g. one could switch ASRC to DP mode, and ASRC implements a
.trigger()method.Reproduction Rate
100%
Expected behavior
Should be redirected to the DP thread as other
struct module_interfacemethods.Impact
Currently none, but will become severe once unsigned DP modules become accepted
Environment
"main"