Getting Started with QNX Neutrino - QNX Software Systems

Examples
© 2009, QNX Software Systems GmbH & Co. KG.
Steps 3 & 4
To calculate how many bytes we can actually return to the client, we perform steps 3
and 4, which figure out how many bytes are available on the device (by taking the total
device size from ocb -> attr -> nbytes and subtracting the current offset into
the device). Once we know how many bytes are left, we take the smaller of that
number and the number of bytes that the client specified that they wish to read. For
example, we may have seven bytes left, and the client wants to only read two. In that
case, we can return only two bytes to the client. Alternatively, if the client wanted
4096 bytes, but we had only seven left, we could return only seven bytes.
Step 5
Now that we’ve calculated how many bytes we’re going to return to the client, we
need to do different things based on whether or not we’re returning data. If we are
returning data, then after the check in step 5, we reply to the client with the data.
Notice that we use data_string + off to return data starting at the correct offset
(the off is calculated based on the xtype override). Also notice the second parameter to
MsgReply() — it’s documented as the status argument, but in this case we’re using it
to return the number of bytes. This is because the implementation of the client’s read()
function knows that the return value from its MsgSendv() (which is the status
argument to MsgReply(), by the way) is the number of bytes that were read. This is a
common convention.
Step 6
Since we’re returning data from the device, we know that the device has been
accessed. We set the IOFUNC_ATTR_ATIME and IOFUNC_ATTR_DIRTY_TIME bits
in the flags member of the attribute structure. This serves as a reminder to the io_stat()
function that the access time is not valid and should be fetched from the system clock
before replying. If we really wanted to, we could have stuffed the current time into the
atime member of the attributes structure, and cleared the
IOFUNC_ATTR_DIRTY_TIME flag. But this isn’t very efficient, since we’re expecting
to get a lot more read() requests from the client than stat() requests. However, your
usage patterns may dictate otherwise.
So which time does the client see when it finally does call stat()? The
iofunc_stat_default() function provided by the resource manager library will look at
the flags member of the attribute structure to see if the times are valid (the atime,
ctime, and mtime fields). If they are not (as will be the case after our io_read() has
been called that returned data), the iofunc_stat_default() function will update the
time(s) with the current time. The real value of the time is also updated on a close(), as
you’d expect.
258 Chapter 5 • Resource Managers April 30, 2009