llext: add dynamic heap allocation support

[alexivanov-google]

Some applications require loading extensions into the memory which does not exist during the boot time and cannot be allocated statically. Make the application responsible for LLEXT heap allocation. Do not allocate LLEXT heap statically.

[github-actions]

Hello @alexivanov-google, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[teburd]

Please squash commits

[alexivanov-google]

squashed

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alexivanov-google]

Do I need to trigger presubmit rerun somehow? Could not find the right "button" :)

[pillo79]

Thanks. I have a few minor nitpicks on the current code, and two bigger questions for you:

• can you give a brief usage example? Are there any alternatives to basically pasting the same line in the app?
• what happens if you call LLEXT APIs while the heap is not allocated? I was expecting additional checks at least in llext_mem.c. Is that implicit with heap APIs?

[pillo79]

default n is implicit, can be removed

[pillo79]

Please mention how to do this as well. I suppose you need to define llext_heap in the app?

[pillo79]

Move this before LLEXT_HEAP_SIZE. Make that entry conditional on !LLEXT_HEAP_DYNAMIC, since specifying the size becomes useless with a dynamic heap.

[alexivanov-google]

Hi Luca,

thanks for looking at the patch!

My system does not have enough RAM to execute the code that is only needed for the boot-time hardware initialization. LLEXT to the rescue: I build the code that runs the initialization flow as an LLEXT module. During my boot time I can configure a temporary scratchpad memory bank. This is done dynamically, the scratchpad is not available during the main application body loading phase. So now, comes the problem with the heap, as I don't want to allocate the heap in the main RAM, it is only needed during the LLEXT execution phase, after which the scratchpad (and the LLEXT stack) disappears. So I am declaring the LLEXT heap in the app and initialize the heap in the scratchpad memory as follows:

/* setup the scratchpad memory bank */
struct k_heap llext_heap;
k_heap_init(&llext_heap, scratchpad_addr, llext_heap_size);
/* load my extension, execute out of the scratchpad */
/* deallocate the scratchpad memory bank */

Currently if the heap is not initialized by the application, the application crashes, the heap API is not checking for null pointers. If we are to check for a null pointer in the LLEXT API, I have some questions:

1. Should I check in llext_load() or is there a better place to check?
2. How can I check for application failure to initialize the llext_heap? I do not see an API such as k_heap_is_initialized(& llext_heap). I can write one, but should it be based on checking which field of struct k_heap?
3. Should I declare a dynamic heap inside the LLEXT subsystem code instead? Then I can pass the heap address/size in struct llext_load_param to llext_load() and allocate the heap there?
4. Make another LLEXT API call to allocate the heap, or do something else to allocate/place the LLEXT heap onto specific address?