Getting Started with QNX Neutrino - QNX Software Systems

More documents

Recommendations

Info

Writing a resource manager © 2009, QNX Software Systems GmbH & Co. KG. connect_funcs and io_funcs These are simply the list of connect functions and I/O functions that you wish to bind to the mountpoint. handle This is an “extendable” data structure (aka “attributes structure”) that identifies the resource being mounted. For example, for a serial port, you’d extend the standard POSIX-layer attributes structure by adding information about the base address of the serial port, the baud rate, etc. Note that it does not have to be an attributes structure — if you’re providing your own “open” handler, then you can choose to interpret this field any way you wish. It’s only if you’re using the default iofunc_open_default() handler as your “open” handler that this field must be an attributes structure. The flags member can contain any of the following flags (or the constant 0 if none are specified): _RESMGR_FLAG_BEFORE or _RESMGR_FLAG_AFTER These flags indicate that your resource manager wishes to be placed before or after (respectively) other resource managers with the same mountpoint. These two flags would be useful with union’d (overlaid) filesystems. We’ll discuss the interactions of these flags shortly. _RESMGR_FLAG_DIR This flag indicates that your resource manager is taking over the specified mountpoint and below — it’s effectively a filesystem style of resource manager, as opposed to a discretely-manifested resource manager. _RESMGR_FLAG_OPAQUE If set, prevents resolving to any other manager below your mount point except for the path manager. This effectively eliminates unioning on a path. _RESMGR_FLAG_FTYPEONLY This ensures that only requests that have the same FTYPE_* as the file_type passed to resmgr_attach() are matched. _RESMGR_FLAG_FTYPEALL This flag is used when a resource manager wants to catch all client requests, even those with a different FTYPE_* specification than the one passed to resmgr_attach() in the file_type argument. This can only be used in conjunction with a registration file type of FTYPE_ALL. _RESMGR_FLAG_SELF Allow this resource manager to talk to itself. This really is a “Don’t try this at home, kids” kind of flag, because allowing a resource manager to talk to itself can break the send-hierarchy and lead to deadlock (as was discussed in the Message Passing chapter). 212 Chapter 5 • Resource Managers April 30, 2009
© 2009, QNX Software Systems GmbH & Co. KG. Writing a resource manager You can call resmgr_attach() as many times as you wish to mount different mountpoints. You can also call resmgr_attach() from within the connect or I/O functions — this is kind of a neat feature that allows you to “create” devices on the fly. When you’ve decided on the mountpoint, and want to create it, you’ll need to tell the process manager if this resource manager can handle requests from just anyone, or if it’s limited to handling requests only from clients who identify their connect messages with special tags. For example, consider the POSIX message queue (mqueue) driver. It’s not going to allow (and certainly wouldn’t know what to do with) “regular” open() messages from any old client. It will allow messages only from clients that use the POSIX mq_open(), mq_receive(), and so on, function calls. To prevent the process manager from even allowing regular requests to arrive at the mqueue resource manager, mqueue specified _FTYPE_MQUEUE as the file_type parameter. This means that when a client requests a name resolution from the process manager, the process manager won’t even bother considering the resource manager during the search unless the client has specified that it wants to talk to a resource manager that has identified itself as _FTYPE_MQUEUE. Unless you’re doing something very special, you’ll use a file_type of _FTYPE_ANY, which means that your resource manager is prepared to handle requests from anyone. For the full list of _FTYPE_* manifest constants, take a look in . With respect to the “before” and “after” flags, things get a little bit more interesting. You can specify only one of these flags or the constant 0. Let’s see how this works. A number of resource managers have started, in the order given in the table. We also see the flags they passed for the flags member. Observe the positions they’re given: Resmgr Flag Order 1 _RESMGR_FLAG_BEFORE 1 2 _RESMGR_FLAG_AFTER 1, 2 3 0 1, 3, 2 4 _RESMGR_FLAG_BEFORE 1, 4, 3, 2 5 _RESMGR_FLAG_AFTER 1, 4, 3, 5, 2 6 0 1, 4, 6, 3, 5, 2 As you can see, the first resource manager to actually specify a flag always ends up in that position. (From the table, resource manager number 1 was the first to specify the “before” flag; no matter who registers, resource manager 1 is always first in the list. Likewise, resource manager 2 was the first to specify the “after” flag; again, no matter who else registers, it’s always last.) If no flag is specified, it effectively acts as a “middle” flag. When resource manager 3 started with a flag of zero, it got put into the middle. As with the “before” and “after” flags, there’s a preferential ordering given to April 30, 2009 Chapter 5 • Resource Managers 213
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: Advanced topics © 2009, QNX Softwa
Page 180 and 181: Advanced topics © 2009, QNX Softwa
Page 183: Chapter 4 Interrupts In this chapte
Page 186 and 187: Neutrino and interrupts © 2009, QN
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 227: © 2009, QNX Software Systems GmbH
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Page 289 and 290:
Page 291 and 292:
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?