[Bug 1253] New: Core Constuctors

[rtems-bugs at rtems.org]

http://www.rtems.org/bugzilla/show_bug.cgi?id=1253

           Summary: Core Constuctors
           Product: RTEMS
           Version: 4.8
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: cpukit
        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 
'_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.

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.
    */
   _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 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.