developer-guide: add LLEXT module documentation #493

lyakh · 2024-04-11T12:22:11Z

Describe LLEXT loadable module support in SOF.

marc-hb · 2024-04-12T06:32:49Z

developer_guides/firmware/llext_modules.rst

+Installation
+************
+
+As described in :ref:`intel_debug_introduction` the |SOF| Linux kernel driver


Unless I missed something that page does not really "describe" anything; it merely gives a /lib/firmware location.

@marc-hb wording updated

marc-hb · 2024-04-12T06:33:23Z

developer_guides/firmware/llext_modules.rst

+************
+
+As described in :ref:`intel_debug_introduction` the |SOF| Linux kernel driver
+loads SOF modules, using their UUIDs. For SOF internal modules the process


What does "using their UUIDs" mean? How does the kernel know which modules to load and which not?

@marc-hb Topology specifies UUIDs, the kernel driver also parses the base firmware manifest to see which UUIDs are built-in. For any, that are specified in topology but aren't available in the base firmware, an attempt will be made to load them dynamically. But this is generic SOF architecture information, not LLEXT specific

Thanks, I think I found it at _apps-component-overview, please add a link to that.

Earlier you mentioned that a single LLEXT file can have multiple modules, in that case which UUID is used for its filename?

Earlier you mentioned that a single LLEXT file can have multiple modules, in that case which UUID is used for its filename?

@marc-hb none. Filenames are created from a common name: "eq_iir," "mixin_mixout," etc. UUIDs are soft links to those files

Did you mean "all of them"? As in:

UUID1.bin -> module1and2combined.llext UUID2.bin -> module1and2combined.llext

developer_guides/firmware/llext_modules.rst

marc-hb · 2024-04-30T21:54:29Z

developer_guides/firmware/llext_modules.rst

+A TOML configuration file is needed for building of LLEXT modules too. It is
+generated by the C preprocessor at build time from the same components, as would
+be used for a monolithic build. A small additional file to bring components
+together is needed too, similar to


"A small additional file to bring components together" is not decriptive; very vague. Having an example is great but it's not a substitute for a description.

developer_guides/firmware/llext_modules.rst

marc-hb · 2024-04-30T22:01:36Z

developer_guides/firmware/llext_modules.rst

+With that in place, it is also possible to switch between monolithic and modular
+builds by specifying the module as "tristate" in its Kconfig and selecting "m"
+for modular builds, however, for modules, exclusively built as LLEXT objects,
+this might not be necessary. Thus it is possible to implement third party Module


By "not necessary" you mean "not possible"? As in "exclusively". I think I'm guessing what you mean but this is confusing.

@marc-hb no, I didn't mean that. I don't know if anybody would want to write modules that they never need to build into the actual SOF image.

I'm still confused sorry. I guess I don't understand what is a "module exclusively built as LLEXT object". Sounds like you select "monolithic" but that is ignored by some modules? Why?

@marc-hb no, that isn't what I meant. I just meant, that if you're sure to only build your code as a loadable LLEXT module, it doesn't matter what you do in your Kconfig, you can just hard fix it to always build as a module.

I still have no idea how you "hard fix" the build-as-module and how the Kconfig gets ignored in that case (which is confusing?)

@marc-hb this is what I currently use to switch to building a loadable module: https://github.com/thesofproject/sof/blob/fdb67ee782808f6d5488a53441cdecd75f458677/zephyr/CMakeLists.txt#L874 If you only ever build your code as such, you don't need that if, you use that code unconditionally.

https://github.com/thesofproject/sof/blob/fdb67ee782808f6d5488a53441cdecd75f458677/zephyr/CMakeLists.txt#L874 seems to build a totally distinct .c file depending on whether the user selects "module" or "built-in". This looks... wrong: unexpected and very confusing. Is this what this section tries to allude to?

If something can only be built as a module, IMHO then the build should fail when the user selects "built-in". It should not silently switch to a different .c file :-(

marc-hb · 2024-04-30T22:04:29Z

developer_guides/firmware/llext_modules.rst

+Adapter drivers, that would be built exclusively as loadable modules.
+
+Note, that a single LLEXT object file can also contain multiple Module Adapter
+modules. In that case an array of ``struct sof_module_api_build_info`` objects


Is EXPORT_SYMBOL() required between these? Or is that not supported yet?

This "multiple modules inside one module" does not look like a "note", more like a key design aspect. It should be moved near the top of this section.

Is EXPORT_SYMBOL() required between these? Or is that not supported yet?

no, that isn't needed. It's a single ELF image.

marc-hb · 2024-04-30T22:10:50Z

developer_guides/firmware/llext_modules.rst

+************
+
+As described in :ref:`intel_debug_introduction` the |SOF| Linux kernel driver
+loads SOF modules, using their UUIDs. For SOF internal modules the process


Thanks, I think I found it at _apps-component-overview, please add a link to that.

Earlier you mentioned that a single LLEXT file can have multiple modules, in that case which UUID is used for its filename?

developer_guides/firmware/llext_modules.rst

deb-intel · 2024-05-14T22:13:17Z

@marc-hb Are you satisfied with the updates?

lgirdwood · 2024-05-22T16:03:45Z

@marc-hb ping

marc-hb · 2024-05-22T18:26:39Z

developer_guides/firmware/llext_modules.rst

+With that in place, it is also possible to switch between monolithic and modular
+builds by specifying the module as "tristate" in its Kconfig and selecting "m"
+for modular builds, however, for modules, exclusively built as LLEXT objects,
+this might not be necessary. Thus it is possible to implement third party Module


https://github.com/thesofproject/sof/blob/fdb67ee782808f6d5488a53441cdecd75f458677/zephyr/CMakeLists.txt#L874 seems to build a totally distinct .c file depending on whether the user selects "module" or "built-in". This looks... wrong: unexpected and very confusing. Is this what this section tries to allude to?

If something can only be built as a module, IMHO then the build should fail when the user selects "built-in". It should not silently switch to a different .c file :-(

marc-hb · 2024-05-22T18:28:14Z

developer_guides/firmware/llext_modules.rst

+
+As specified in
+:ref:`Firmware look-up paths per Intel platform <intel_firmware_paths>`
+the |SOF| Linux kernel driver loads SOF modules, using their UUIDs. For SOF


Suggested change

the |SOF| Linux kernel driver loads SOF modules, using their UUIDs. For SOF

the |SOF| Linux kernel driver loads SOF modules with UUIDs specified in the topology. For SOF

Please mention briefly that UUIDs.bin are symbolic links and that several of them can point to the same LLEXT file. Again, a link to _apps-component-overview would probably be good.

marc-hb · 2024-05-22T18:29:55Z

developer_guides/firmware/llext_modules.rst

+As specified in
+:ref:`Firmware look-up paths per Intel platform <intel_firmware_paths>`
+the |SOF| Linux kernel driver loads SOF modules, using their UUIDs. For SOF
+internal modules the process of creation


What does "internal" mean? Available in https://github.com/thesofproject/sof I'm guessing?

In the context of SOF, "internal" usually means "not open-source".

Suggest: "for modules in the main SOF repo"

marc-hb · 2024-05-22T18:37:19Z

developer_guides/firmware/llext_modules.rst

+As explained above, LLEXT modules in general look very similar to native SOF
+code, with the only restriction of having no access to not-exported symbols. If
+any such symbols are needed to LLEXT modules, additionally exporting them can be
+considered.


I don't understand this last sentence sorry, what does "additionally" mean?

I can't decide whether this sentence is merely repeating that modules can only access exported symbols (in which case it should be dropped), or too briefly alluding to some other, more complex development question.

developer_guides/firmware/llext_modules.rst

marc-hb · 2024-05-22T19:07:36Z

developer_guides/firmware/llext_modules.rst

+
+A TOML configuration file is needed for building of LLEXT modules too. It is
+generated by the C preprocessor at build time from the same components, as would
+be used for a monolithic build. For this preprocessor run a small header file,


I'm not a "English comma expert" but I really struggled to parse this sentence (also because run is both a noun and a verb). I think this is what it means:

Suggested change

be used for a monolithic build. For this preprocessor run a small header file,

be used for a monolithic build. For this preprocessor run, a small header file that ...

Describe LLEXT loadable module support in SOF. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

lyakh requested review from lgirdwood, deb-intel, intelkevinputnam, mmaka1 and mwasko as code owners April 11, 2024 12:22

lyakh mentioned this pull request Apr 11, 2024

llext: install modules appropriately for testing thesofproject/sof#9013

Merged

lyakh requested review from plbossart and marc-hb April 11, 2024 13:58

marc-hb reviewed Apr 12, 2024

View reviewed changes

lyakh force-pushed the llext branch from b49ef79 to 7e2ef71 Compare April 29, 2024 14:58

lgirdwood previously approved these changes Apr 30, 2024

View reviewed changes

marc-hb reviewed Apr 30, 2024

View reviewed changes

mwasko requested a review from marcinszkudlinski May 8, 2024 07:19

lyakh dismissed lgirdwood’s stale review via 78c2a05 May 13, 2024 10:55

lyakh force-pushed the llext branch from 7e2ef71 to 78c2a05 Compare May 13, 2024 10:55

lyakh requested review from marc-hb and lgirdwood May 13, 2024 10:55

lgirdwood previously approved these changes May 14, 2024

View reviewed changes

marc-hb reviewed May 22, 2024

View reviewed changes

marc-hb mentioned this pull request Aug 13, 2024

LLEXT - security aspects zephyrproject-rtos/zephyr#76700

Open

lyakh mentioned this pull request Aug 28, 2024

[DNM][POC] asoc: sof: add a hard-coded array of loadable extensions thesofproject/linux#5156

Draft

lyakh dismissed lgirdwood’s stale review via 521b4e4 August 28, 2024 10:50

lyakh force-pushed the llext branch from 78c2a05 to 521b4e4 Compare August 28, 2024 10:50

developer-guide: add LLEXT module documentation

38828e5

Describe LLEXT loadable module support in SOF. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

lyakh force-pushed the llext branch from 521b4e4 to 38828e5 Compare August 28, 2024 11:49

lgirdwood approved these changes Sep 13, 2024

View reviewed changes

lgirdwood merged commit 8c2a968 into thesofproject:master Sep 13, 2024
4 checks passed

lyakh deleted the llext branch September 16, 2024 06:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

developer-guide: add LLEXT module documentation #493

developer-guide: add LLEXT module documentation #493

lyakh commented Apr 11, 2024

marc-hb Apr 12, 2024

lyakh Apr 29, 2024

marc-hb Apr 12, 2024

lyakh Apr 29, 2024

marc-hb Apr 30, 2024

lyakh May 7, 2024

marc-hb May 7, 2024

marc-hb Apr 30, 2024

marc-hb Apr 30, 2024

lyakh May 13, 2024

marc-hb May 14, 2024

lyakh May 15, 2024

marc-hb May 15, 2024

lyakh May 16, 2024

marc-hb May 22, 2024

marc-hb Apr 30, 2024

lyakh May 13, 2024

marc-hb Apr 30, 2024

deb-intel commented May 14, 2024

lgirdwood commented May 22, 2024

marc-hb May 22, 2024

marc-hb May 22, 2024

marc-hb May 22, 2024

marc-hb May 22, 2024

marc-hb May 22, 2024

marc-hb May 22, 2024

	the \|SOF\| Linux kernel driver loads SOF modules, using their UUIDs. For SOF
	the \|SOF\| Linux kernel driver loads SOF modules with UUIDs specified in the topology. For SOF

	be used for a monolithic build. For this preprocessor run a small header file,
	be used for a monolithic build. For this preprocessor run, a small header file that ...

developer-guide: add LLEXT module documentation #493

developer-guide: add LLEXT module documentation #493

Conversation

lyakh commented Apr 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deb-intel commented May 14, 2024

lgirdwood commented May 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment