Lines Matching +full:llext +full:- +full:edk

4 The following Kconfig options are available for the LLEXT subsystem:
9 ----------
11 The LLEXT subsystem needs a static heap to be allocated for extension related
16         Size of the LLEXT heap in kilobytes.
27 ---------------
29 The LLEXT subsystem supports loading different types of extensions; the type
34         Build and expect relocatable files as binary object type for the LLEXT
41         object type for the LLEXT subsystem. These object files are generated
46         Build and expect shared libraries as binary object type for the LLEXT
57 --------------------
59 The LLEXT subsystem loading mechanism, by default, uses a seek/read abstraction
63 LLEXT subsystem to optimize memory footprint in this case.
87            <https://github.com/zephyrproject-rtos/zephyr/issues/75341>`_.
92 -----------------------------
94 When an extension is loaded, the LLEXT subsystem must find the address of all
96 To this end, the main binary contains a LLEXT-dedicated symbol table, filled
97 with one symbol-name-to-address mapping entry for each symbol exported by the
99 LLEXT linker at extension load time. This process is pretty slow due to the
107         a pointer-sized hash called Symbol Link Identifier (SLID), which is
111         integer-based comparisons rather than string-based ones. Another
112         benefit of SLID-based linking is that storing symbol names in the
118            This option is not currently compatible with the :ref:`LLEXT EDK
129 EDK configuration
130 -----------------
132 Options influencing the generation and behavior of the LLEXT EDK are described