Choosing the configuration method for rtems_allocator

General
1

Hello,

As part of the rtems_allocator integration, we need to decide how applications should select the heap allocator used by RTEMS.

There are two main decisions.

Static or runtime configuration

The allocator could be selected statically at build time:

#define CONFIGURE_HEAP_ALLOCATOR RTEMS_ALLOCATOR_TLSF

Alternatively, the allocator could be selected at runtime by constructing or registering an rtems_allocator object.

One allocator or separate allocators

RTEMS normally has two heap instances:

  • _Workspace_Area, used for internal RTEMS objects.
  • RTEMS_Malloc_Heap, used by functions such as malloc().

We could use one configured allocator implementation for both heaps:

#define CONFIGURE_HEAP_ALLOCATOR RTEMS_ALLOCATOR_TLSF

Alternatively, users could configure them separately:

#define CONFIGURE_WORKSPACE_HEAP_ALLOCATOR RTEMS_ALLOCATOR_FIRST_FIT
#define CONFIGURE_MALLOC_HEAP_ALLOCATOR    RTEMS_ALLOCATOR_TLSF

When CONFIGURE_UNIFIED_WORK_AREAS is enabled, both use the same heap, so they would have to use the same allocator.

I would like feedback on the following questions:

  1. Should allocator selection happen at build time or runtime?
  2. Should the workspace and malloc heaps always use the same allocator?
  3. Is there a use case for configuring the two heaps separately?
  4. How should applications obtain the configured workspace or malloc rtems_allocator object when direct access is needed?
2

I could imagine wanting to use different allocators for the two heaps, because they serve different purposes. In general, the workspace allocation will all occur during system initialization, and likely there is not much deallocation (free), so a simple allocator probably works well there. The program heap however will have much more complex behavior and so a complex heap allocator might be desired by the application.

I cannot see any good reason to configure it dynamically. Regarding the static configuration, in addition to the options you have (confdefs style), it might also be possible to configure at RTEMS build time (config.ini). There is a similar discussion going on at Updating the RTEMS Classic Attributes to support a semaphore kind mask.

Regarding point 4, why would an application need to access the rtems_allocator object directly?

3

Networking apps like EPICS create and delete threads all the time and that effects the workspace.

1 Like
4

Okay, We can give the user the option to configure each heap however he thinks is best.

I will make it configurable statically too since as you say it makes more sense.

An application needs to access rtems_allocator to do any of the heap operations.
for example
rtems_allocator_allocate_aligned_with_boundary( &Allocator, size, alignment, boundary, &address );