T-Kernel Specification (1.B0.02)

More documents

Recommendations

Info

208 CHAPTER 4. T-KERNEL/OS FUNCTIONS SVC handler will return to its caller before the break function finished executing, but in that case the extended SVC handler waits at the point right before returning, until the break function completes. How this wait state maps to the task state transitions is implementation-dependent, but preferably it should remain in READY state (a READY state that does not go to RUN state). The precedence of a task may change while it is waiting for a break function to complete, but how task precedence is treated is implementation-dependent. Similarly, an extended SVC handler cannot call an extended SVC until break function execution completes. In other words, during the time from the raising of a task interrupt until the break function completes, the affected task must stay in the extended SVC handler that was executing at the time of the task exception. If a break function and extended SVC handler run in different task contexts and the break function task priority is lower than the extended SVC handler task priority, the task priority of the break function is raised to the same priority as the extended SVC handler task only during the time while the break handler is executing. On the other hand, if the break function task priority is the same as or higher than that of the extended SVC handler, the priority does not change. The priority that gets changed is the current priority; the base priority stays the same. The change in priority occurs only right before entry into the break function; any changes after that in the extended SVC handler task priority are not followed up by further changes in priority of the break function task. In no case does a change in the break function priority while a break function is running result in a priority change in the extended SVC handler task. At the same time there is no restriction on priority changes because a break function is running. When the break function completes, the current priority of its task reverts to base priority. If a mutex was locked, however, the priority reverts to that as adjusted by the mutex. (In other words, the ability is provided to adjust the current priority at the entry and exit of the break function only; other than that, the priority is the same as when an ordinary task is running.) • Startup function A startup function is called by issuing the tk sta ssy system call. It performs resource control block initialization processing. The format of a startup function is as follows. void startupfn( ID resid, INT info ) { /* Resource control block initialization processing */ } resid is the ID of the resource group to be initialized, and info is a parameter that can be used in any way. Both are passed to tk sta ssy. Even if initialization of the resource control block fails for some reason, the startup function must be terminated normally. If the resource control block could not be initialized, then when an API (extended SVC) that cannot be executed normally as a result is called, error is passed in the return code of that API. A startup function runs as a quasi-task portion in the context of the task that called tk sta ssy. • Cleanup function A cleanup function is called by issuing the tk cln ssy system call, and performs resource release processing. The format of a cleanup function is as follows. Copyright c○ 2002, 2003 by T-Engine Forum T-Kernel 1.B0.02
4.10. SUBSYSTEM MANAGEMENT FUNCTIONS 209 void cleanupfn( ID resid, INT info ) { /* Resource release processing */ } resid is the ID of the resource group subject to resource release, while info is a parameter that can be used freely. Both are parameters passed to tk cln ssy. Even if resource release fails for some reason, the cleanup function must be terminated normally. The error handling, such as logging of errors, can be decided for each subsystem. After the cleanup function completes its processing, the resource control block is automatically cleared to 0. If no cleanup function was defined (cleanupfn = NULL), the tk cln ssy system call clears the resource control block to 0. A cleanup function runs as a quasi-task portion in the context of the task that called tk cln ssy. • Event handling function An event handling function is called by issuing the tk evt ssy system call. It processes various requests made to a subsystem. Note that it does not carry the obligation to process all requests for all subsystems. If processing is not required, it can simply return E OK without performing any operation. The format of an event handling function is as follows. ER eventfn( INT evttyp, ID resid, INT info ) { /* Event processing */ return ercd; } evttyp indicates the request type, resid gives the ID of the resource group, and info is a parameter that can be used freely. All these parameters are passed to tk evt ssy. If the system call is not invoked for any particular resource group, resid can be set to 0. If processing completes normally, E OK is passed in the return code; otherwise an error code (negative value) is returned. The following event types evttyp are defined. See 5.3 for details. #define TSEVT_SUSPEND_BEGIN 1 /* before suspending device */ #define TSEVT_SUSPEND_DONE 2 /* after suspending device */ #define TSEVT_RESUME_BEGIN 3 /* before resuming device */ #define TSEVT_RESUME_DONE 4 /* after resuming device */ #define TSEVT_DEVICE_REGIST 5 /* device registration notice */ #define TSEVT_DEVICE_DELETE 6 /* device deletion notice */ An event handling function runs as a quasi-task portion in the context of the task that called tk evt ssy. Copyright c○ 2002, 2003 by T-Engine Forum T-Kernel 1.B0.02
Page 1 and 2:
T-Kernel Specification T-Kernel 1.B
Page 3 and 4:
Contents 1 T-Kernel Overview 1 1.1
Page 5 and 6:
CONTENTS v tk set flg (Set Event Fl
Page 7 and 8:
CONTENTS vii 5.2.2 Address Space Ch
Page 9 and 10:
CONTENTS ix td cal que (Reference Q
Page 11 and 12:
List of Figures 1.1 Position of T-K
Page 13 and 14:
List of Tables 2.1 State Transition
Page 15 and 16:
System Call Notation In the parts o
Page 17 and 18:
Index of T-Kernel/OS System Calls T
Page 19 and 20:
INDEX OF T-KERNEL/OS SYSTEM CALLS x
Page 21 and 22:
Index of T-Kernel/SM Extended SVC L
Page 23 and 24:
Index of T-Kernel/DS System Calls T
Page 25 and 26:
Chapter 1 T-Kernel Overview 1.1 Pos
Page 27 and 28:
1.2. SCALABILITY 3 • Middleware m
Page 29 and 30:
Chapter 2 Concepts Underlying the T
Page 31 and 32:
2.2. TASK STATES AND SCHEDULING RUL
Page 33 and 34:
2.2. TASK STATES AND SCHEDULING RUL
Page 35 and 36:
2.3. INTERRUPT HANDLING 11 preceden
Page 37 and 38:
2.5. SYSTEM STATES 13 Transient sta
Page 39 and 40:
2.7. MEMORY 15 which the upper and
Page 41 and 42:
Chapter 3 Common T-Kernel Specifica
Page 43 and 44:
3.2. SYSTEM CALLS 19 /* * Common co
Page 45 and 46:
3.2. SYSTEM CALLS 21 Ordinarily a f
Page 47 and 48:
3.3. HIGH-LEVEL LANGUAGE SUPPORT RO
Page 49 and 50:
Chapter 4 T-Kernel/OS Functions Thi
Page 51 and 52:
4.1. TASK MANAGEMENT FUNCTIONS 27 t
Page 53 and 54:
4.1. TASK MANAGEMENT FUNCTIONS 29 #
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
4.2. TASK-DEPENDENT SYNCHRONIZATION
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
4.3. TASK EXCEPTION HANDLING FUNCTI
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
4.4. SYNCHRONIZATION AND COMMUNICAT
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
4.5. EXTENDED SYNCHRONIZATION AND C
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
4.6. MEMORY POOL MANAGEMENT FUNCTIO
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182: 4.6. MEMORY POOL MANAGEMENT FUNCTIO
Page 187 and 188: 4.7. TIME MANAGEMENT FUNCTIONS 163
Page 209 and 210: 4.8. INTERRUPT MANAGEMENT FUNCTIONS
Page 215 and 216: 4.9. SYSTEM MANAGEMENT FUNCTIONS 19
Page 229 and 230: 4.10. SUBSYSTEM MANAGEMENT FUNCTION
Page 231: 4.10. SUBSYSTEM MANAGEMENT FUNCTION
Page 243 and 244: Chapter 5 T-Kernel/SM Details of th
Page 245 and 246: 5.1. SYSTEM MEMORY MANAGEMENT FUNCT
Page 247 and 248: 5.2. ADDRESS SPACE MANAGEMENT FUNCT
Page 249 and 250: 5.2. ADDRESS SPACE MANAGEMENT FUNCT
Page 251 and 252: 5.3. DEVICE MANAGEMENT FUNCTIONS 22
Page 275 and 276: 5.5. IO PORT ACCESS SUPPORT FUNCTIO
Page 277 and 278: 5.7. SYSTEM CONFIGURATION INFORMATI
Page 279 and 280: 5.7. SYSTEM CONFIGURATION INFORMATI
Page 281: 5.8. SUBSYSTEM AND DEVICE DRIVER ST
Page 284 and 285:
260 CHAPTER 6. T-KERNEL/DS FUNCTION
Page 286 and 287:
Page 288 and 289:
Page 290 and 291:
Page 292 and 293:
Page 294 and 295:
Page 296 and 297:
Page 298 and 299:
Page 300 and 301:
Page 302 and 303:
Page 304 and 305:
Page 306 and 307:
Page 308 and 309:
284 CHAPTER 7. REFERENCE INT tevptn
Page 310 and 311:
286 CHAPTER 7. REFERENCE ER ercd =
Page 312 and 313:
288 CHAPTER 7. REFERENCE INT ct = t
Page 314:
290 CHAPTER 7. REFERENCE E OACV ERC
show all

T-Kernel Specification (1.B0.02)

Create successful ePaper yourself

Delete template?

Save as template?