General notes

Each handler function gets passed an internal context block (the ctp argument) that should be treated as “read-only,” except for the iov member. This context block contains a few items of interest, as described above in resmgr_context_t internal context block.” Also, each function gets passed a pointer to the message (in the msg argument). You'll be using this message pointer extensively, as that contains the parameters that the client's C library call has placed there for your use.

The function that you supply must return a value (all functions are prototyped as returning in int). The values are selected from the following list:

Indicates to the resource manager library that it should not perform the MsgReplyv()—the assumption is that you've either performed it yourself in your handler function, or that you're going to do it some time later.
The resource manager library should return an n-part IOV when it does the MsgReplyv() (the IOV is located in ctp -> iov). Your function is responsible for filling in the iov member of the ctp structure, and then returning _RESMGR_NPARTS() with the correct number of parts.
Note: The iov member of ctp is allocated dynamically, so it must be big enough to hold the number of array elements that you're writing into the iov member! See the section resmgr_attr_t control structure” above, for information on setting the nparts_max member.
This instructs the resource manager library to perform the low-level default function (This is not the same as the iofunc_*_default() functions!) You'd rarely ever use this return value. In general, it causes the resource manager library to return an errno of ENOSYS to the client, which indicates that the function is not supported.
An errno value
Indicates to the resource manager library that it should call MsgError() with this value as the error parameter. This generally causes the client function (e.g., open()) to return -1 and set errno on the client side to the returned value.
_RESMGR_ERRNO ( errno )
(Deprecated) This return value had been used to “wrap” an errno number as the return value of the message. For example, if a client issued an open() request for a read-only device, it would be appropriate to return the error value EROFS. Since this function is deprecated, you can return the error number directly instead of wrapping it with the _RESMGR_ERRNO() macro (e.g., return (EROFS); instead of the more cumbersome return (_RESMGR_ERRNO (EROFS));.)
_RESMGR_PTR ( ctp, addr, len )
This is a convenience macro that accepts the context pointer ctp, and fills its first IOV element to point to the address specified by addr for the length specified by len, and then returns the equivalent of _RESMGR_NPARTS (1) to the library. You'd generally use this if you return single-part IOVs from your function.