LLEXT: libraries with multiple modules #9688
Conversation
|
SOFCI TEST |
Split man_get_module_manifest() into two functions in preparation for multi-part relocatable module library support. Signed-off-by: Guennadi Liakhovetski <[email protected]>
The second preparatory step for multi-part relocatable module libraries. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Rimage generates an image from multiple input modules. However, in case of building libraries from multiple relocatable ELF files it doesn't currently construct manifest correctly. It mixes up manifest provided in TOML with manifest structures in ".module" sections of modules. Clean this up to only use manifests from ELF and append configuration from TOML. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Run-time loadable SOF libraries can contain multiple modules. To prepare to support them add a module context type. Signed-off-by: Guennadi Liakhovetski <[email protected]>
NULL checking should be done before dereferencing, not after. Also rearrange varoable definition in llext_manager_allocate_module() to make it more logical. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Loadable libraries can contain multiple modules, where each module can contain multiple manifest entries, e.g. when providing multiple Module Adapter drivers. This commit adds support for such libraries, built by specifying all the modules on rimage command line. Signed-off-by: Guennadi Liakhovetski <[email protected]>
mux.toml doesn't have a demux entry in it, therefore we cannot have one in .module either, remove it until fixed. Also fix a copy-paste error in the same code block. Signed-off-by: Guennadi Liakhovetski <[email protected]>
lyakh
requested review from
fkwasowi,
lgirdwood,
plbossart,
mmaka1,
lbetlej,
dbaluta and
kv2019i
as code owners
| /* | ||
| * The demux entry is removed because mtl.toml doesn't have an entry | ||
| * for it. Once that is fixed, the manifest line below can be | ||
| * re-activated: | ||
| * #define UUID_DEMUX 0x68, 0x68, 0xB2, 0xC4, 0x30, 0x14, 0x0E, 0x47, 0x89, 0xA0, \ | ||
| * 0x15, 0xD1, 0xC7, 0x7F, 0x85, 0x1A | ||
| * SOF_LLEXT_MOD_ENTRY(demux, &demux_interface); | ||
| */ |
There was a problem hiding this comment.
Do we need an entry for demux for legacy reasons ? if so, can we followup with a PR that adds the demux UUID ?
There was a problem hiding this comment.
@lgirdwood sure we can restore it if needed, but we need a full TOML entry for it for that, we don't have one ATM
There was a problem hiding this comment.
ok, pls just copy the mux CPC data for demux and add inline comment. The toml CPC data is in need of tuning in general anyway.
There was a problem hiding this comment.
@lgirdwood my current demux change is a pure compile-time one. Demux is currently disabled in both monolithic and modular IPC4 Intel builds. Also, even for compilation, this change only affects modular mux/demux builds, which we don't do either in any default configurations anyway. Whereas if I add a demux TOML entry, it will affect the generated binary, it will add a demux driver, where we haven't got one until now. So I would prefer to do that in a separate PR.
|
@kv2019i good for you ? |
| @@ -316,27 +316,27 @@ uintptr_t llext_manager_allocate_module(struct processing_module *proc, | |||
| { | |||
| uint32_t module_id = IPC4_MOD_ID(ipc_config->id); | |||
There was a problem hiding this comment.
"varoable definition" in git commit message
| if (ctx->mod[i].start_idx > idx) | ||
| break; | ||
|
|
||
| return i - 1; |
There was a problem hiding this comment.
what if "ctx->mod[0].startidx > idx" is true? this would return (unsigned)-1
There was a problem hiding this comment.
@kv2019i it cannot be true by construction - the first module always starts from 0. I can add a comment in an incremental PR
| * index and then also check the driver name. | ||
| * We also need the driver size. For this we search the manifest array | ||
| * for the next ELF file, then the difference between offsets gives us | ||
| * the driver size. |
Add support for libraries with multiple modules. This handles loading of libraries. Creation will be added later, isn't too complex, needs minor additions to cmake and Python.