[PATCH 0/5] Optimize workspace/malloc initialization

[Karel Gardas]

Hi Sebastian,

just a question. Do you plan to preserve functionality of _Heap_Extend()
in the future? Asking since I'm using it for amd64/uefi bsp. During the
bsp start I get efi services pointers and use that to traverse memory
map. Based on available free blocks I try to allocate memory using EFI
API and if successful I'm calling _Heap_Extend with it to pass ram to
RTEMS. That's the way I found out by searching in the tree in lpc24xx
and lpc176x bsps. Pity I've not found altera-cyclone-v at that time
since this looks even more similar to what I need to achieve here. Will
need to analyze it better (weekend task).

As I'm still trying to understand better memory allocation in RTEMS, I'm
of course open to any idea how to implement this in the most clean way
acceptable for RTEMS and not using _Heap_Extend() -- if it would not be
allowed or right thing to do or scheduled for future removal.

Thanks!
Karel

On 11/29/21 11:29 AM, Sebastian Huber wrote:
> The BSPs provide memory for the RTEMS Workspace and the separate C
> Program Heap initialization via _Memory_Get().  Most BSPs provide
> exactly one memory area.  Only two BSPs provide more than one memory
> area (arm/altera-cyclone-v and bsps/powerpc/mpc55xxevb).  Only if more
> than one memory area is provided, there is a need to use _Heap_Extend().
> Provide two implementations to initialize the RTEMS Workspace and the
> separate C Program Heap.  Let the BSP select one of the implementations
> based on the number of provided memory areas.  This gets rid of a
> dependency on _Heap_Extend().  It also avoids dead code sections for
> most BSPs.
> 
> Sebastian Huber (5):
>   wkspace.c: Change license to BSD-2-Clause
>   score: Split wkspace.c
>   build: Use common objects item for get memory
>   score: Optimize Workspace Handler initialization
>   libc: Optimize malloc() initialization