| 161 | = Summary of the last week irc meeting = |
| 162 | |
| 163 | |
| 164 | Last week Sebhub, Chris, Joel and me make a irc meeting to discuss the implement of Rtems |
| 165 | Sequenced Initialization API. Here i make a summary for this meeting: |
| 166 | |
| 167 | First we talked about the disadvantage of run time sort apporach. This solution needs space |
| 168 | to store the order information and the code to sort the items, so it is not suitable for the |
| 169 | embedded system which has little RAM. Then the practicability of the link time sort approach |
| 170 | was discussed. This solution exploits the GNU ld sort feature to order the Sequenced |
| 171 | Initialization information in the specifical section. Because it is a lexicographical sort |
| 172 | we 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 |
| 174 | we can manage the list a little better, for example in a group we define 0->20 for uses and |
| 175 | 100-?? for others. By the way because of the diffcult of maintainance we discard the "Linux |
| 176 | Approach". 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 |
| 177 | there is no similar call like rtems_message_queue_creat which the application must call or |
| 178 | it will fail. So we must consider another method to solve this problem. |