The base layer

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

The bottom-most layer consists of functions that begin with resmgr_*() in their names. This class of function is concerned with the mechanics of making a resource manager work.

I'll just briefly mention the functions that are available and where we'd use them. I'll then refer you to the QNX documentation for additional details on these functions.

The base layer functions consist of:

resmgr_msggetv() and resmgr_msgget()
Use an optimal combination of copying local message buffer data and reading data from the client's address space using a kernel call. These functions avoid reading data from the client's address space when possible.
resmgr_msgwritev() and resmgr_msgwrite()
Use a kernel call to write data to the client's address space.
resmgr_open_bind()
Associates the context from a connect function, so that it can be used later by an I/O function. In most cases, you'll want to have this function called for you via a function like iofunc_ocb_attach() or iofunc_open_default() to take advantage of the additional functionality they provide.
resmgr_attach()
Associates a pathname, dispatch handle, connect functions, I/O functions, and other parameters together. Sends a message to the process manager to register the pathname. QNX recommends that, in most cases, you perform these actions using secpol_resmgr_attach() instead, because it also allows you to set permissions, ownership, and ACLs based on a security policy (go to The secpol_resmgr_attach() and resmgr_attach() functions and their parameters).
resmgr_detach()
Opposite of resmgr_attach(); dissociates the binding of the pathname and the resource manager.
pulse_attach()
Associates a pulse code with a function. Since the library implements the message receive loop, this is a convenient way of gaining control for handling pulses.
pulse_detach()
Dissociates a pulse code from the function.

In addition to the functions listed above, there are also numerous functions dealing with the dispatch interface.

One function from the above list that deserves special mention is resmgr_open_bind(). It associates some form of context data when the connect message (typically as a result of the client calling open() or fopen()) arrives, so that this data block is around when the I/O messages are being handled. Why didn't we see this in the /dev/null handler? Because the POSIX-layer default functions call this function for us. If we're handling all the messages ourselves, we'd certainly call this function.

Note:
The resmgr_open_bind() function not only sets up the context block for further I/O messages, but also initializes other data structures used by the resource manager library itself.

The rest of the functions from the above list are somewhat intuitive—we'll defer their discussion until we use them.

Page updated: