[Bug 1253] New: Core Constuctors
rtems-bugs at rtems.org
rtems-bugs at rtems.org
Wed Aug 22 20:04:36 CDT 2007
Summary: Core Constuctors
AssignedTo: chrisj at rtems.org
ReportedBy: chrisj at rtems.org
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
To start the linked in managers the RTEMS API initialise becomes:
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.
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
You are the assignee for the bug, or are watching the assignee.
More information about the rtems-bugs