Expose Rust Global Allocator to LVGL C code #49

New issue

Open

opened 2021-05-26 19:03:57 +00:00 by rafaelcaricio · 1 comment

rafaelcaricio commented

2021-05-26 19:03:57 +00:00

(Migrated from github.com)

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.

We could enable the LVGL side to [use Rust memory allocator](https://github.com/ezrosent/allocators-rs/tree/master/malloc-bind), if it's available and the feature "alloc" enabled in lvgl-rs. That way we wouldn't need to use [our custom `Box` implementation](https://github.com/rafaelcaricio/lvgl-rs/blob/56cb470dc8b021ffdce4fb30ea29ff9dd0aa34c7/lvgl/src/mem.rs#L10) 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](https://github.com/rustwasm/wee_alloc#about). 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](https://github.com/rafaelcaricio/lvgl-rs/blob/56cb470dc8b021ffdce4fb30ea29ff9dd0aa34c7/lvgl/src/mem.rs#L10) at all, since the memory space would be shared by LVGL C and Rust.

rafaelcaricio commented

2021-05-27 21:22:02 +00:00

(Migrated from github.com)

On this topic, this is a very interesting option to consider using in LVGL-rs and recommending to users:

https://github.com/vcombey/fallible_collections

This allows to handle allocation errors when using collections.

On this topic, this is a very interesting option to consider using in LVGL-rs and recommending to users: - https://github.com/vcombey/fallible_collections This allows to handle allocation errors when using collections.