Getting Started with QNX Neutrino - QNX Software Systems

More documents

Recommendations

Info

Handler routines © 2009, QNX Software Systems GmbH & Co. KG. Device dev inode rdev /dev/hd0 6 2 1 /dev/hd0t77 1 12 77 /hd/spud.txt 77 47343 N/A Handler routines For the raw block device, /dev/hd0, the process manager assigned both the dev and inode values (the 6 and the 2 in the table above). The resource manager picked a unique rdev value (of 1) for the device when it started. For the partition, /dev/hd0t77, the dev value came from the raw block device’s rdev number (the 1). The inode was selected by the resource manager as a unique number (within the rdev). This is where the 12 came from. Finally, the rdev number was selected by the resource manager as well — in this case, the writer of the resource manager selected 77 because it corresponded to the partition type. Finally, for the file, /hd/spud.txt, the dev value (77) came from the partition’s rdev value. The inode was selected by the resource manager (in the case of a file, the number is selected to correspond to some internal representation of the file — it doesn’t matter what it is so long as it’s not zero, and it’s unique within the rdev). This is where the 47343 came from. For a file, the rdev field is not meaningful. Not all outcalls correspond to client messages — some are synthesized by the kernel, and some by the library. I’ve organized this section into the following: • general notes • connect functions notes followed by an alphabetical listing of connect and I/O messages. General notes Each handler function gets passed an internal context block (the ctp argument) which should be treated as “read-only,” except for the iov member. This context block contains a few items of interest, as described above in “resmgr_context_t internal context block.” Also, each function gets passed a pointer to the message (in the msg argument). You’ll be using this message pointer extensively, as that contains the parameters that the client’s C library call has placed there for your use. The function that you supply must return a value (all functions are prototyped as returning in int). The values are selected from the following list: 226 Chapter 5 • Resource Managers April 30, 2009
© 2009, QNX Software Systems GmbH & Co. KG. Handler routines _RESMGR_NOREPLY _RESMGR_NPARTS (n) Indicates to the resource manager library that it should not perform the MsgReplyv() — the assumption is that you’ve either performed it yourself in your handler function, or that you’re going to do it some time later. The resource manager library should return an n-part IOV when it does the MsgReplyv() (the IOV is located in ctp -> iov). Your function is responsible for filling in the iov member of the ctp structure, and then returning _RESMGR_NPARTS with the correct number of parts. The iov member of ctp is allocated dynamically, so it must be big enough to hold the number of array elements that you’re writing into the iov member! See the section “resmgr_attr_t control structure” above, for information on setting the nparts_max member. _RESMGR_DEFAULT An errno value _RESMGR_ERRNO (errno) _RESMGR_PTR (ctp, addr, len) This instructs the resource manager library to perform the low-level default function (This is not the same as the iofunc_*_default() functions!) You’d rarely ever use this return value. In general, it causes the resource manager library to return an errno of ENOSYS to the client, which indicates that the function is not supported. Indicates to the resource manager library that it should call MsgError() with this value as the error parameter. This generally causes the client function (e.g. open()) to return -1 and set errno on the client side to the returned value. (Deprecated) This return value had been used to “wrap” an errno number as the return value of the message. For example, if a client issued an open() request for a read-only device, it would be appropriate to return the error value EROFS. Since this function is deprecated, you can return the error number directly instead of wrapping it with the _RESMGR_ERRNO macro (e.g., return (EROFS); instead of the more cumbersome return (_RESMGR_ERRNO (EROFS));.) This is a convenience macro that accepts the context pointer ctp, and fills its first IOV element to point to the address specified by addr for the length specified by len, and then returns the equivalent of _RESMGR_NPARTS (1) to the library. You’d generally use this if you return single-part IOVs from your function. April 30, 2009 Chapter 5 • Resource Managers 227
Page 1 and 2:
QNX Neutrino RTOS Getting Started w
Page 3 and 4:
Contents About This Guide xi What y
Page 5 and 6:
© 2009, QNX Software Systems GmbH
Page 7 and 8:
Page 9 and 10:
List of Figures A process as a cont
Page 11:
About This Guide April 30, 2009 Abo
Page 14 and 15:
Typographical conventions © 2009,
Page 17:
Foreword to the First Edition by Pe
Page 20 and 21:
Page 23 and 24:
Page 25 and 26:
Page 27:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
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:
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:
Page 95:
Chapter 2 Message Passing In this c
Page 98 and 99:
Message passing and client/server
Page 100 and 101:
Message passing and client/server
Page 102 and 103:
Multiple threads © 2009, QNX Softw
Page 104 and 105:
Multiple threads © 2009, QNX Softw
Page 106 and 107:
Using message passing © 2009, QNX
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Pulses © 2009, QNX Software System
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Message passing over a network © 2
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Priority inheritance © 2009, QNX S
Page 148 and 149:
Priority inheritance © 2009, QNX S
Page 151:
Chapter 3 Clocks, Timers, and Getti
Page 154 and 155:
Clocks and timers © 2009, QNX Soft
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Using timers © 2009, QNX Software
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Advanced topics © 2009, QNX Softwa
Page 178 and 179:
Page 180 and 181:
Page 183:
Chapter 4 Interrupts In this chapte
Page 186 and 187:
Neutrino and interrupts © 2009, QN
Page 188 and 189:
Page 190 and 191:
Page 192 and 193: Writing interrupt handlers © 2009,
Page 200 and 201: TIME TIME Writing interrupt handler
Page 204 and 205: Summary © 2009, QNX Software Syste
Page 207 and 208: © 2009, QNX Software Systems GmbH
Page 241: © 2009, QNX Software Systems GmbH
Page 293 and 294:
Page 295 and 296:
Page 297 and 298:
Page 299:
Page 303 and 304:
Page 305 and 306:
Page 307 and 308:
Page 309 and 310:
Page 311 and 312:
Page 313 and 314:
Page 315 and 316:
Page 317 and 318:
Page 319:
Appendix B Calling 911 In this appe
Page 322 and 323:
Seeking professional help © 2009,
Page 324 and 325:
Seeking professional help © 2009,
Page 327:
Appendix C Sample Programs In this
Page 330 and 331:
atoz.c © 2009, QNX Software System
Page 332 and 333:
atoz.c © 2009, QNX Software System
Page 334 and 335:
time1.c © 2009, QNX Software Syste
Page 336 and 337:
time1.c © 2009, QNX Software Syste
Page 338 and 339:
tp1.c © 2009, QNX Software Systems
Page 340 and 341:
tt1.c © 2009, QNX Software Systems
Page 343 and 344:
Page 345 and 346:
Page 347 and 348:
Page 349 and 350:
Page 351 and 352:
Index ! /dev/null resource manager
Page 353 and 354:
Page 355 and 356:
Page 357 and 358:
Page 359 and 360:
Page 361 and 362:
Page 363 and 364:
Page 365 and 366:
Page 367 and 368:
Page 369 and 370:
Page 371 and 372:
Page 373 and 374:
Page 375 and 376:
Page 377 and 378:
Page 379 and 380:
Page 381 and 382:
Page 383 and 384:
Page 385 and 386:
Page 387 and 388:
show all

Getting Started with QNX Neutrino - QNX Software Systems

Create successful ePaper yourself

Delete template?

Save as template?