Changes between Version 37 and Version 38 of Developer/Projects/SequencedInitialization


Ignore:
Timestamp:
Jun 15, 2010, 12:25:48 PM (9 years ago)
Author:
Wenjie1984
Comment:

/* Open Projects */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Projects/SequencedInitialization

    v37 v38  
    159159= Open Projects =
    160160
     161=  Summary of the last week irc meeting  =
     162
     163
     164Last week Sebhub, Chris, Joel and me make a irc meeting to discuss the implement of Rtems
     165Sequenced Initialization API. Here i make a summary for this meeting:
     166
     167First we talked about the disadvantage of run time sort apporach. This solution needs space
     168to store the order information and the code to sort the items, so it is not suitable for the
     169embedded system which has little RAM. Then the practicability of the link time sort approach
     170was discussed. This solution exploits the GNU ld sort feature to order the Sequenced
     171Initialization information in the specifical section. Because it is a lexicographical sort
     172we can define domains of ordering to make a combination term.  Such as "rtems_seq_0002" or
     173"rtems_seq_0020", there are not limited in the number of domains. We can also add a group so
     174we can manage the list a little better, for example in a group we define 0->20 for uses and
     175100-?? for others. By the way because of the diffcult of maintainance we discard the "Linux
     176Approach". Last there is also a problem waiting for a appropriate solution to fix it. The problem is how to reference the sysinit_core struct which contains the information of Sequenced Initialization. For example: the application use RTEMS Event and RTEMS Signal API
     177there is no similar call like rtems_message_queue_creat which the application must call or
     178it will fail. So we must consider another method to solve this problem.
    161179=  Components Of Rtems Sequenced Initialization API  =
    162180