[DNM] llext_manager: Fix for multipipeline issue with llext #8939
Conversation
Now llext_manager_link funtions gets struct llext **llext instead of struct module_data *md. Signed-off-by: Adrian Warecki <[email protected]>
Moved the llext handle to the module context. Each module instance has its own module_data structure, which resulted in the module being loaded every time. Signed-off-by: Adrian Warecki <[email protected]>
softwarecki
requested review from
lgirdwood,
plbossart,
mmaka1,
lbetlej,
dbaluta and
kv2019i
as code owners
|
@softwarecki one question: have you tested these patches with llext and in particular with the scenario that you are trying to fix - with multiple pipelines? If not, let's put some "Do Not Merge" indication in the PRs title. It's currently a draft, but would be safer to keep a reminder there too. Unfortunately we don't yet have LLEXT tests in the CI (yes, I'm working towards that) and without testing these changes are too intrusive to verify just by reading. |
src/library_manager/llext_manager.c
Outdated
| @@ -267,6 +270,7 @@ uintptr_t llext_manager_allocate_module(struct processing_module *proc, | |||
| return 0; | |||
| } | |||
|
|
|||
| ctx->instance_count++; | |||
There was a problem hiding this comment.
no need. LLEXT in Zephyr already does refcounting.
softwarecki
changed the title
|
@lyakh Don't treat it like a real PR. I created it just to show my vision of where I thought the zephyr llext handle should be stored. The |
Thanks, it wasn't quite clear, that this was just an "idea demonstration," not a real PR. With a "DNM" prefix now it's clearer. |
The
module_datastructure is unique for each module instance. We will not be able to tell whether this is the first loading of the module based on the value of any of its fields. I moved thellextstructure to the module context and added an instance counter to protect against loading the module code into memory for subsequent instances. When releasing a module, we check whether it was the last instance of it.