Getting Started with QNX Neutrino - QNX Software Systems

Writing a resource manager
© 2009, QNX Software Systems GmbH & Co. KG.
Putting in your own functions
all the “middle” resource managers, whereby newer ones are placed in front of other,
existing “middle” ones.
However, in reality, there are very few cases where you’d actually mount more than
one, and even fewer cases where you’d mount more than two resource managers at the
same mountpoint. Here’s a design tip: expose the ability to set the flags at the
command line of the resource manager so that the end-user of your resource manager
is able to specify, for example, -b to use the “before” flag, and -a to use the “after”
flag, with no command-line option specified to indicate that a zero should be passed as
the flag.
Keep in mind that this discussion applies only to resource managers mounted with the
same mountpoint. Mounting “/nfs” with a “before” flag and “/disk2” with an
“after” flag will have no effect on each other; only if you were to then mount another
“/nfs”or“/disk2” would these flags (and rules) come into play.
Finally, the resmgr_attach() function returns a small integer handle on success (or -1
for failure). This handle can then be used subsequently to detach the pathname from
the process manager’s internal pathname tables.
When designing your very first resource manager, you’ll most likely want to take an
incremental design approach. It can be very frustrating to write thousands of lines of
code only to run into a fundamental misunderstanding and then having to make the
ugly decision of whether to try to kludge (er, I mean “fix”) all that code, or scrap it and
start from scratch.
The recommended approach for getting things running is to use the iofunc_func_init()
POSIX-layer default initializer function to fill the connect and I/O tables with the
POSIX-layer default functions. This means that you can literally write your initial cut
of your resource manager as we did above, in a few function calls.
Which function you’ll want to implement first really depends on what kind of resource
manager you’re writing. If it’s a filesystem type of resource manager where you’re
taking over a mountpoint and everything below it, you’ll most likely be best off
starting with the io_open() function. On the other hand, if it’s a discretely manifested
resource manager that does “traditional” I/O operations (i.e., you primarily access it
with client calls like read() and write()), then the best place to start would be the
io_read() and/or io_write() functions. The third possibility is that it’s a discretely
manifested resource manager that doesn’t do traditional I/O operations, but instead
relies on devctl() or ioctl() client calls to perform the majority of its functionality. In
that case, you’d start at the io_devctl() function.
Regardless of where you start, you’ll want to make sure that your functions are getting
called in the expected manner. The really cool thing about the POSIX-layer default
functions is that they can be placed directly into the connect or I/O functions table.
This means that if you simply want to gain control, perform a printf() to say “I’m here
in the io_open!”, and then “do whatever should be done,” you’re going to have an easy
214 Chapter 5 • Resource Managers April 30, 2009