Getting Started with QNX Neutrino - QNX Software Systems

Examples
© 2009, QNX Software Systems GmbH & Co. KG.
}
}
// 8) tell the resource manager library to do the reply, and that it
// was okay
return (EOK);
As you can see, a few of the initial operations performed were identical to those done
in the io_read() example — the iofunc_write_verify() is analogous to the
iofunc_read_verify() function, and the xtype override check is the same.
Step 1
Here we performed much the same processing for the “xtype override” as we did in
the io_read() example, except for the fact that the offset is not stored as part of the
incoming message structure. The reason it’s not stored there is because a common
practice is to use the size of the incoming message structure to determine the starting
point of the actual data being transferred from the client. We take special pains to
ensure the offset of the start of the data (doffset) is correct in the xtype handling code.
Step 2
Here we allocate a buffer that’s big enough for the data. The number of bytes that the
client is writing is presented to us in the nbytes member of the msg union. This is
stuffed automatically by the client’s C library in the write() routine. Note that if we
don’t have sufficient memory to handle the malloc() request, we return the error
number ENOMEM to the client — effectively, we’re passing on the return code to the
client to let it know why its request wasn’t completed.
Step 3
Here we use the helper function resmgr_msgread() to read the entire data content from
the client directly into the newly allocated buffer. In most cases we could have just
used MsgRead(), but in the case where this message is part of a “combine message,”
resmgr_msgread() performs the appropriate “magic” for us (see the “Combine
message” section for more information on why we need to do this.) The parameters to
resmgr_msgread() are fairly straightforward; we give it the internal context pointer
(ctp), the buffer into which we want the data placed (buffer), and the number of bytes
that we wish read (the nbytes member of the message msg union). The last parameter
is the offset into the current message, which we calculated above, in step 1. The offset
effectively skips the header information that the client’s C library implementation of
write() put there, and proceeds directly to the data. This actually brings about two
interesting points:
• We could use an arbitrary offset value to read chunks of the client’s data in any
order and size we want.
• We could use resmgr_msgreadv() (note the “v”) to read data from the client into an
IOV, perhaps describing various buffers, similar to what we did with the cache
buffers in the filesystem discussion in the Message Passing chapter.
262 Chapter 5 • Resource Managers April 30, 2009