1Configuration
2#############
3
4The following Kconfig options are available for the LLEXT subsystem:
5
6.. _llext_kconfig_heap:
7
8Heap size
9----------
10
11The LLEXT subsystem needs a static heap to be allocated for extension related
12data. The following option controls this allocation.
13
14:kconfig:option:`CONFIG_LLEXT_HEAP_SIZE`
15
16        Size of the LLEXT heap in kilobytes.
17
18.. note::
19
20   When :ref:`user mode <usermode_api>` is enabled, the heap size must be
21   large enough to allow the extension sections to be allocated with the
22   alignment required by the architecture.
23
24.. _llext_kconfig_type:
25
26ELF object type
27---------------
28
29The LLEXT subsystem supports loading different types of extensions; the type
30can be set by choosing among the following Kconfig options:
31
32:kconfig:option:`CONFIG_LLEXT_TYPE_ELF_OBJECT`
33
34        Build and expect relocatable files as binary object type for the LLEXT
35        subsystem. A single compiler invocation is used to generate the object
36        file.
37
38:kconfig:option:`CONFIG_LLEXT_TYPE_ELF_RELOCATABLE`
39
40        Build and expect relocatable (partially linked) files as the binary
41        object type for the LLEXT subsystem. These object files are generated
42        by the linker by combining multiple object files into a single one.
43
44:kconfig:option:`CONFIG_LLEXT_TYPE_ELF_SHAREDLIB`
45
46        Build and expect shared libraries as binary object type for the LLEXT
47        subsystem. The standard linking process is used to generate the shared
48        library from multiple object files.
49
50        .. note::
51
52           This is not currently supported on ARM architectures.
53
54.. _llext_kconfig_storage:
55
56Minimize allocations
57--------------------
58
59The LLEXT subsystem loading mechanism, by default, uses a seek/read abstraction
60and copies all data into allocated memory; this is done to allow the extension
61to be loaded from any storage medium. Sometimes, however, data is already in a
62buffer in RAM and copying it is not necessary. The following option allows the
63LLEXT subsystem to optimize memory footprint in this case.
64
65:kconfig:option:`CONFIG_LLEXT_STORAGE_WRITABLE`
66
67        Allow the extension to be loaded by directly referencing section data
68        into the ELF buffer. To be effective, this requires the use of an ELF
69        loader that supports the ``peek`` functionality, such as the
70        :c:struct:`llext_buf_loader`.
71
72        .. warning::
73
74           The application must ensure that the buffer used to load the
75           extension remains allocated until the extension is unloaded.
76
77        .. note::
78
79           This will directly modify the contents of the buffer during the link
80           phase. Once the extension is unloaded, the buffer must be reloaded
81           before it can be used again in a call to :c:func:`llext_load`.
82
83        .. note::
84
85           This is currently required by the Xtensa architecture. Further
86           information on this topic is available on GitHub issue `#75341
87           <https://github.com/zephyrproject-rtos/zephyr/issues/75341>`_.
88
89.. _llext_kconfig_slid:
90
91Using SLID for symbol lookups
92-----------------------------
93
94When an extension is loaded, the LLEXT subsystem must find the address of all
95the symbols residing in the main application that the extension references.
96To this end, the main binary contains a LLEXT-dedicated symbol table, filled
97with one symbol-name-to-address mapping entry for each symbol exported by the
98main application to extensions. This table can then be searched into by the
99LLEXT linker at extension load time. This process is pretty slow due to the
100nature of string comparisons, and the size consumed by the table can become
101significant as the number of exported symbols increases.
102
103:kconfig:option:`CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID`
104
105        Perform an extra processing step on the Zephyr binary and on all
106        extensions being built, converting every string in the symbol tables to
107        a pointer-sized hash called Symbol Link Identifier (SLID), which is
108        stored in the binary.
109
110        This speeds up the symbol lookup process by allowing usage of
111        integer-based comparisons rather than string-based ones. Another
112        benefit of SLID-based linking is that storing symbol names in the
113        binary is no longer necessary, which provides a significant decrease in
114        symbol table size.
115
116        .. note::
117
118           This option is not currently compatible with the :ref:`LLEXT EDK
119           <llext_build_edk>`.
120
121        .. note::
122
123           Using a different value for this option in the main binary and in
124           extensions is not supported. For example, if the main application
125           is built with ``CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID=y``, it is
126           forbidden to load an extension that was compiled with
127           ``CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID=n``.
128
129EDK configuration
130-----------------
131
132Options influencing the generation and behavior of the LLEXT EDK are described
133in :ref:`llext_kconfig_edk`.
134