Add LVGL Rust Global Allocator feature #48

2021-05-25T23:08:18Z

rafaelcaricio commented

2021-05-25 23:08:18 +00:00

(Migrated from github.com)

Fixes #46

New optional feature that registers a Rust global memory allocator implementation that uses the LVGL memory management API. All allocations go to the LVGL managed memory location.

Fixes #46 New optional feature that registers a Rust global memory allocator implementation that uses the LVGL memory management API. All allocations go to the LVGL managed memory location.

rafaelcaricio (Migrated from github.com) reviewed 2021-05-26 13:33:25 +00:00

lvgl/src/lib.rs

					
				@ -27,0 +46,4 @@

				//

				#[cfg(not(feature = "lvgl_alloc"))]

				use crate::mem::Box;

rafaelcaricio (Migrated from github.com) commented

2021-05-26 13:33:25 +00:00

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 implement this custom Box implementation for that case. We would still need this implementation for cases where all features in lvgl-rs are disabled and we cannot assume that LVGL is using the same memory space.

The problem 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 implement this custom `Box` implementation for that case. We would still need this implementation for cases where all features in lvgl-rs are disabled and we cannot assume that LVGL is using the same memory space. The problem 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 at all, since the memory space would be shared by LVGL C and Rust.

Sign in to join this conversation.

No reviewers