Notice: We have migrated to GitLab launching 2024-05-01 see here:

#1253 closed enhancement

Core Constuctors

Reported by: Chris Johns Owned by: Chris Johns
Priority: lowest Milestone: 4.9
Component: score Version: 4.9
Severity: minor Keywords:
Cc: Blocked By:

Description (last modified by Chris Johns)

Core constructors is a trial for a new feature that automatically manages the initialisation of managers.

I have been playing with the idea of CORE constructors for RTEMS for a while
as a means to remove the need for dummy functions as a way to stub out
unwanted parts of RTEMS. The specific example is the need for the
MANAGERS_NOT_WANTED in makefiles and the c/src/opman/rtems source files. I
think a suitable means to resolve the specific example of the RTEMS classic
API should be able to move onto other parts of RTEMS. I have a working patch
for the RTEMS classic API.

The idea is "you only get what you use". If you create a task and semaphore
you get those parts of RTEMS linked in. The function per file does most of the
work linking into the application only the task and semaphore calls used. The
missing part is the manager initialise.

In the cpukit/rtems/src/sem.c file a constructor node is added:

RTEMS_CTOR( classic, semaphore, 8, _Semaphore_Manager_initialization );

The nodes are currently a tree. The parent is 'classic' for the RTEMS Classic
API, the name is 'semaphore', the start order is 8 and the function to call is

In the cpukit/rtems/src/semcreate.c file a constructor reference is added:

RTEMS_CTOR_REF( classic, semaphore );

The references are at the leaf of the tree and pull in all above. Each
constructor node has its pointer placed in a special section and a modified
linker script pulls those pointers together. This is similar to the sysctl system.

To start the linked in managers the RTEMS API initialise becomes:

void _RTEMS_API_Initialize(

rtems_configuration_table *configuration_table


rtems_api_configuration_table *api_configuration;

api_configuration = configuration_table->RTEMS_api_configuration;

_Objects_Information_table[OBJECTS_CLASSIC_API] = _RTEMS_Objects;


  • The attribute handler is not a function rather a macro so
  • cannot make it a constructor. */


_CORE_construct( &RTEMS_CTOR_NODE_PARENT( classic ), api_configuration );


I have built the pc386 BSP and run a number of samples and tests. My code
currently has the no-*.c code commented out.

The downsize of this approach is the addition of extra data to hold the
constructor and the reference. The constructor is currently 20 bytes and a
reference is 4 bytes. The constructor size could be reduced as I did not try
to make it as small as I could while playing. A constructor only adds to the
size when you use the resource. In the case of the RTEMS API where are 13
constructors and you would only get all if you used every API resource. In the
case of a task and semaphore application the overhead is 48 bytes. The
smallest the constructor could be come is 12 bytes with usage restrictions.

On the positive side is the reduced size of the RTEMS API initialise call.
This is at the cost of 3 functions used to perform the construction. On the
pc386 this is 320 bytes but is shared across all of RTEMS. The other advantage
is the removal from the source tree of the no-managers and the removal of
Makefile and linking tricks. There will also be a benefit for those who have
never looked at this and link everything.

I think the next layer up, the Classic, POSIX and ITRON API could be handled
in a similar way. If this is possible an application that does not use ITRON
would not get anything pulled in. This becomes attractive when releasing
binary cpukits. The file-system could also be the same if a place to reference
the constructor can be found. For example the 'mount' call.

Attachments (1)

head-constructor-managers.diff (58.5 KB) - added by Chris Johns on 08/23/07 at 00:08:03.
Proof of concept patch.

Download all attachments as: .zip

Change History (5)

Changed on 08/23/07 at 00:08:03 by Chris Johns

Proof of concept patch.

comment:1 Changed on 08/23/07 at 00:08:03 by Chris Johns

The patch proves this can be done and allows the size of data used to be measured. It only supports the pc386. If you wish to use other BSPs the linker command file will need to modifed like the pc386 one.

comment:2 Changed on 11/08/07 at 22:32:42 by Chris Johns

Milestone: 4.84.9
Status: newassigned

comment:3 Changed on 11/20/14 at 03:48:53 by Chris Johns

Description: modified (diff)
Resolution: wontfix
Status: assignedclosed

Not for a release branch.

comment:4 Changed on 11/20/14 at 03:50:34 by Chris Johns

Version: 4.84.9
Note: See TracTickets for help on using tickets.