Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Writing a resource manager
We’ll look at:
• The resmgr_attach() function and its parameters
• Putting in your own functions
• The general flow of a resource manager
• Messages that should be connect messages but aren’t
• Combine messages
The resmgr_attach() function and its parameters
As you saw in the /dev/null example above, the first thing you’ll want to do is
register your chosen “mountpoint” with the process manager. This is done via
resmgr_attach(), which has the following prototype:
int
resmgr_attach (void *dpp,
resmgr_attr_t *resmgr_attr,
const char *path,
enum _file_type file_type,
unsigned flags,
const resmgr_connect_funcs_t *connect_funcs,
const resmgr_io_funcs_t *io_funcs,
RESMGR_HANDLE_T *handle);
Let’s examine these arguments, in order, and see what they’re used for.
dpp
resmgr_attr
path
file_type
flags
The dispatch handle. This lets the dispatch interface manage the
message receive for your resource manager.
Controls the resource manager characteristics, as discussed above.
The mountpoint that you’re registering. If you’re registering a
discrete mountpoint (such as would be the case, for example, with
/dev/null,or/dev/ser1), then this mountpoint must be matched
exactly by the client, with no further pathname components past the
mountpoint. If you’re registering a directory mountpoint (such as
would be the case, for example, with a network filesystem mounted
as /nfs), then the match must be exact as well, with the added
feature that pathnames past the mountpoint are allowed; they get
passed to the connect functions stripped of the mountpoint (for
example, the pathname /nfs/etc/passwd would match the
network filesystem resource manager, and it would get etc/passwd
as the rest of the pathname).
The class of resource manager. See below.
Additional flags to control the behavior of your resource manager.
These flags are defined below.
April 30, 2009 Chapter 5 • Resource Managers 211