Getting Started with QNX Neutrino - QNX Software Systems

Writing a resource manager
© 2009, QNX Software Systems GmbH & Co. KG.
id
msg_max_size
status
offset
size
iov
The identifier for the mountpoint this message was meant for.
When you did the resmgr_attach(), it returned a small integer ID.
This ID is the value of the id member. Note that you’d most likely
never use this parameter yourself, but would instead rely on the
attributes structure passed to you in your io_open() handler.
This contains the msg_max_size that was passed in as the
msg_max_size member of resmgr_attr_t (given to the
resmgr_attach() function) so that the size, offset, and
msg_max_size are all contained in one handy structure/location.
This is where your handler function places the result of the
operation. Note that you should always use the macro
_RESMGR_STATUS to write this field. For example, if you’re
handling the connect message from an open(), and you’re a
read-only resource manager but the client wanted to open you for
write, you’d return an EROFS errno via (typically)
_RESMGR_STATUS (ctp, EROFS).
The current number of bytes into the client’s message buffer. Only
relevant to the base layer library when used with
resmgr_msgreadv() with combine messages (see below).
This tells you how many bytes are valid in the message area that
gets passed to your handler function. This number is important
because it indicates if more data needs to be read from the client
(for example, if not all of the client’s data was read by the
resource manager base library), or if storage needs to be allocated
for a reply to the client (for example, to reply to the client’s read()
request).
The I/O Vector table where you can write your return values, if
returning data. For example, when a client calls read() and your
read-handling code is invoked, you may need to return data. This
data can be set up in the iov array, and your read-handling code
can then return something like _RESMGR_NPARTS (2) to
indicate (in this example) that both iov [0] and iov [1]
contain data to return to the client. Note that the iov member is
defined as only having one element. However, you’ll also notice
that it’s conveniently at the end of the structure. The actual
number of elements in the iov array is defined by you when you
set the nparts_max member of the control structure above (in the
section “resmgr_attr_t control structure,” above).
Resource manager structure
Now that we’ve seen the data structures, we can discuss interactions between the parts
that you’d supply to actually make your resource manager do something.
210 Chapter 5 • Resource Managers April 30, 2009