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_msgreadv() and resmgr_msgread()

Reads data from the client's address space using message passing.

resmgr_msgwritev() and resmgr_msgwrite()

Writes data to the client's address space using message passing.

resmgr_open_bind()

Associates the context from a connect function, so that it can be used later by an I/O function.

resmgr_attach()

Creates a channel, 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.

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.