Changes between Version 117 and Version 118 of Developer/OpenProjects


Ignore:
Timestamp:
Mar 25, 2009, 3:09:28 AM (11 years ago)
Author:
JoelSherrill
Comment:

/* RTEMS Sequenced Initialization */ Minor corrections and additions

Legend:

Unmodified
Added
Removed
Modified
  • Developer/OpenProjects

    v117 v118  
    189189
    190190
    191 '''Status:''' [wiki:ChrisJohns ChrisJohns] has filed a PR with a prototype.
     191'''Status:''' [wiki:ChrisJohns ChrisJohns] has filed [https://www.rtems.org/bugzilla/show_bug.cgi?id=1253 PR1253] with a prototype.
    192192
    193193'''Mentor:''' Chris Johns
     
    195195  '''Note:''' this project was called "RTEMS Initialization By Constructor".
    196196
    197 This project adds to RTEMS a Sequencer that calls user defined functions held in an unordered table in a specific order. An example of its use is the RTEMS Managers initialisation. The initialisation of the RTEMS Managers is a specific ordered sequence of calls currently hard coded into RTEMS. The sequencing code will take a table of nodes that is un-order, determine the order and make calls to the user provided functios which in this case is the manager initialisation calls.
    198 
    199 The solution should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. The result of this work is expected to impact the [wiki:Projects/TinyRTEMS TinyRTEMS] effort as it would provide a central mechanism to automatically eliminate unused code. If you don't reference a part of the RTEMS API the initialization code would automatically drop out. The automatic part here refers to the creation of the table of nodes.
    200 
    201 A prototype of the work can be found in [https://www.rtems.org/bugzilla/show_bug.cgi?id=1253 PR1253]. This work combines the call sequencing with the automatic generation of the table of nodes. The solution is not suitable as it uses the word "constructor" which we have since decided should not be used, as well as too much RAM. The ideal solution should use little if any RAM and all nodes and tables be held in ROM type memory. A typical small foot print CPU which would use a [wiki:Projects/TinyRTEMS TinyRTEMS] solution has much more ROM than RAM. Also this is a once off initialisation procedure and so using RAM means it is gone from application use.
    202 
    203 The automatic table generation uses the same linker technique used to create C++ static object constructor and destructor tables. Consider the RTEMS Message API. In the Message Manager's initialisation call's source file you create a {{{static const</code> structure with the specific fields needed by the sequencer code then reference this variable from the source file containing the {{{rtems_message_queue_create</code> code. The application must make a call to {{{rtems_message_queue_create</code> or all the other Message API calls will fail therefore this API needs only one reference from a single source file. The application call of {{{rtems_message_queue_create</code> will pull in its code and as this code references the node in the initialisation call's file it is also pulled in along with the initialisation code. We also create a variable that is a pointer to the sequencer node and this is placed in a special section using the GCC "attribute" modifier. The linker command file for BSP is modified to group all these pointers together in one location in ROM. This creates the table that is passed to the sequencer code.
    204 
    205 The sequencer code iterates over the table calling entries in the order specified. The order could be a number or it could be relative. The relative order design makes for a more robust system because you have moved away from specific numbers. The idea here is to allow high level ordering operators, for example "first", "last", "after", "before", "just after", "just before", etc. You can then say "message" is "after" "heap" and the order is determined at runtime. Most system parts are relative not absolute. It may even be possible to allow relative and absolute ordering to be mixed. Priorities are similar. At the end of the day we do not need 256 levels if we only use 4. Typically all we need is to say is this task is higher or lower than another task. Sequencing cab viewed the same way.
     197This project adds to RTEMS a Sequencer that calls user defined functions held in an unordered table in a specific order. An example of its use is the RTEMS Managers initialization. The initialisation of the RTEMS Managers is a specific ordered sequence of calls currently hard coded into RTEMS. The sequencing code will take a table of nodes that is un-order, determine the order and make calls to the user provided functions which in this case is the manager initialisation calls.
     198
     199The solution should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. The result of this work is expected to impact the [wiki:Projects/TinyRTEMS TinyRTEMS] effort as it would provide a central mechanism to automatically eliminate unused code. If you don't reference a part of the RTEMS API the initialization code would automatically drop out. The dropping of unused code is critical to both the [wiki:Projects/TinyRTEMS TinyRTEMS] effort and to those woh use RTEMS in safety-critical systems which must be validated.  The automatic part here refers to the creation of the table of nodes.
     200
     201A prototype of the work can be found in [https://www.rtems.org/bugzilla/show_bug.cgi?id=1253 PR1253]. This work combines the call sequencing with the automatic generation of the table of nodes. The solution is not suitable as it uses the word "constructor" which we have since decided should not be used, as well as too much RAM. The ideal solution should use little if any RAM and all nodes and tables be held in ROM type memory. A typical small foot print CPU which would use a [wiki:Projects/TinyRTEMS TinyRTEMS] solution has much more ROM than RAM. Also this is a once off initialization procedure and so using RAM means it is gone from application use.
     202
     203The automatic table generation uses the same linker technique used to create C++ static object constructor and destructor tables. Consider the RTEMS Message API. In the Message Manager's initialization call's source file you create a {{{static const</code> structure with the specific fields needed by the sequencer code then reference this variable from the source file containing the {{{rtems_message_queue_create</code> code. The application must make a call to {{{rtems_message_queue_create</code> or all the other Message API calls will fail therefore this API needs only one reference from a single source file. The application call of {{{rtems_message_queue_create</code> will pull in its code and as this code references the node in the initialization call's file it is also pulled in along with the initialization code. We also create a variable that is a pointer to the sequencer node and this is placed in a special section using the GCC "attribute" modifier. The linker command file for each BSP must be modified to group all these pointers together in one location in ROM. This creates the table that is passed to the sequencer code.
     204
     205The sequencer code iterates over the table calling entries in the order specified. The order could be a number or it could be relative. The relative order design makes for a more robust system because you have moved away from specific numbers. The idea here is to allow high level ordering operators, for example "first", "last", "after", "before", "just after", "just before", etc. You can then say "message" is "after" "heap" and the order is determined at runtime. Most system parts are relative not absolute. It may even be possible to allow relative and absolute ordering to be mixed. Priorities are similar. At the end of the day we do not need 256 levels if we only use 4. Typically all we need is to say is this task is higher or lower than another task. Sequencing ca viewed the same way.
    206206
    207207This project tasks are:
    208208# Develop the sequencer code and API with documentation and tests.
    209 # Update the RTEMS classic API initialisation calls and if possible the POSIX API initialisation calls with the sequencer implementation using automatic table generation. This also includes removal of the hard coded call with a sequencer call.
    210 # Update all linker command files to handle the initialisation automatic table entries.
     209# Update the RTEMS Classic API, POSIX API and ITRON API initialization calls with the sequencer implementation using automatic table generation. This also includes removal of the hard coded call with a sequencer call.
     210# Update all linker command files to handle the initialization automatic table entries.
     211# Initial testing can all be done on SPARC/sis.  The modification of other BSP linkcmds should be done with caution but mistakes will be caught by Test Builds of RTEMS by [wiki:TBR/User/JoelSherrill JoelSherrill] which include all BSP configurations.
     212
     213Code and data size measurements should be made before and after the implementation is done on the sparc/sis and arm/rtl22xx_t BSPs.  These BSPs are used for code size analysis across releases.
    211214= BSPs for CPU Simulators =
    212215