RFC: Core constructors.

[Chris Johns]

Hi,

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 being used to stub out 
unwanted parts of RTEMS. The specific example is the the MANAGERS_NOT_WANTED 
in makefiles and the c/src/opman/rtems source files. I think a suitable 
solution to resolve this specific problem with the RTEMS classic API should be 
able to move onto other parts of RTEMS. I have a working patch for the RTEMS 
classic API in Bugzilla as PR1253. I filed this PR a while ago so the patch 
may need to be updated.

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
'_Semaphore_Manager_initialization'.

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 in the TCP stack.

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

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.
     */
    _Attributes_Handler_initialization();

    _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 there 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 this 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 played with this aspect of RTEMS and link everything.

I think the next layer up, the Classic, POSIX and ITRON API could be handled 
in a similar way. There could also be a BSP set of constructors. If this is 
possible an application that does not use ITRON would not get anything pulled 
in. This becomes attractive when releasing binary cpukits.

Comments ?

Regards
Chris