User-defined message I/O function handler

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

Prototype:

int (*msg) ( resmgr_context_t *ctp,
             io_msg_t *msg,
             RESMGR_OCB_T *ocb )

Classification:

I/O

Default handler:

none.

Helper functions:

none.

Client function:

none—manually assembled and sent via MsgSend()

Messages:

_IO_MSG

Data structure:

struct _io_msg {
  uint16_t       type;
  uint16_t       combine_len;
  uint16_t       mgrid;
  uint16_t       subtype;
};

typedef union {
  struct _io_msg i;
} io_msg_t;

Description:

Like devctl(), the _IO_MSG interface allows you to send miscellaneous requests. The mgrid is used to identify a particular manager—you should not perform actions for requests that don't conform to your manager ID. The subtype is effectively the command that the client wishes to perform. Any data that's transferred implicitly follows the input structure. Data that's returned to the client is sent on its own, with the status returned via _RESMGR_STATUS().
The methods for validating messages for this handler are the same as for the device control I/O function handler, but note the following differences:
  • Unlike the device control I/O function handler, which has devctl() and devctlv(), the user-defined message handler does not have libc functions to help send messages.
  • The size of the input header is io_msg_t, not io_devctl_t.
  • No output header is defined.

Returns:

The status via the helper macro _RESMGR_STATUS().

Referenced by:

resmgr_io_funcs_t I/O table

Permission checking:

There is no default handler or helper for this function. It handles messages sent manually through MsgSend(). Any permission checking is specific to the function being implemented. If the message handler is supporting a variety of commands similar to devctl(), a per-command access check might be necessary.

For a general discussion of read and write permissions, go to Permission checking in the QNX OS System Security Guide.

Page updated: