Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Advanced topics
Important note
Advanced topics
Extending the OCB
Recall the discussion in the io_write() sample above, about the data area following the
header. To recap, we stated that the bytes following the header may or may not be
complete (i.e., the header may or may not have been read in its entirety from the
client), depending on how much data was read in by the resource manager library.
Then we went on to discuss how it was inefficient to try to “save” a message pass and
to “reuse” the data area. However, things are slightly different with devctl(), especially
if the amount of data being transferred is fairly small (as was the case in our
examples). In these cases, there’s a good chance that the data has in fact been read into
the data area, so it is indeed a waste to re-read the data. There is a simple way to tell
how much space you have: the size member of ctp contains the number of bytes that
are available for you starting at the msg parameter. The size of the data area beyond
the end of the message buffer that’s available is calculated by subtracting the size of
the message buffer from the size member of ctp:
data_area_size = ctp -> size - sizeof (*msg);
Note that this size is equally valid when you are returning data to the client (as in the
DCMD_AUDIO_GET_SAMPLE_RATE command).
For anything larger than the allocated region, you’ll want to perform the same
processing we did with the io_write() example (above) for getting data from the client,
and you’ll want to allocate a buffer to be used for returning data to the client.
Now that we’ve covered the “basics” of resource managers, it’s time to look at some
more complicated aspects:
• extending the OCB
• extending the attributes structure
• blocking within the resource manager
• returning directory entries
In some cases, you may find the need to extend the OCB. This is relatively painless to
do. The common uses for extending the OCB are to add extra flags you wish to
maintain on a per-open basis. One such flag could be used with the io_unblock()
handler to cache the value of the kernel’s _NTO_MI_UNBLOCK_REQ flag. (See the
Message Passing chapter, under “Using the _NTO_MI_UNBLOCK_REQ” for more
details.)
To extend the OCB, you’ll need to provide two functions; one to allocate (and
initialize) the new OCB and one to free it. Then, you’ll need to bind these two
functions into the mount structure. (Yes, this does mean that you’ll need a mount
April 30, 2009 Chapter 5 • Resource Managers 269