RFC: Core constructors.
chrisj at rtems.org
Fri Dec 7 00:08:11 UTC 2007
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
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:
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 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.
More information about the users