Description
We could enable the LVGL side to use Rust memory allocator, if it's available and the feature "alloc" enabled in lvgl-rs. That way we wouldn't need to use our custom Box
implementation for that case. We would still need this implementation for cases where all features in lvgl-rs are disabled and we do not have a Box
abstraction to handover memory to LVGL C.
Some code example of how this could work is available at: https://github.com/ezrosent/allocators-rs/tree/master/malloc-bind
We could get inspiration from the malloc-bind project and implement a similar solution to be used in embedded devices.
The problem we want to solve is that LVGL C always support "dynamically" allocated memory backed by a static array-based backend, just like wee_alloc. LVGL-rs is a library and the choice of allocator must be made by the firmware/application developer. Besides that, the developer might decide that they don't want to have an allocator at all on their Rust firmware. LVGL C will still use their own memory management implementation.
One option is to always require users of LVGL-rs to define a global allocator in their project. This would be a limitation for some use cases?! In that scenario, we wouldn't need the code in mem
module at all, since the memory space would be shared by LVGL C and Rust.