The base layer
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.
The rest of the functions from the above list are somewhat intuitive—we'll defer their discussion until we use them.