Resmgr: io_open_t message handling

Hi,

I have a question related to io_open_t message handling in a resmgr.

Looking at an example for iofunc_open in on-line doc:

http://www.qnx.com/developer/docs/momentics_nc_docs/neutrino/lib_ref/i/iofun
c_open.html

==== QUOTED ====

For example, an open handler that only does pathname redirection may look
something like:

io_open(resmgr_context_t *ctp, io_open_t *msg, iofunc_attr_t *dattr, void
*extra)
{
char *newpath;

/* Do all the error/access checking … */

/* Lookup the redirected path and store
the new path in ‘newpath’ */
newpath = get_a_new_path(msg->connect.path);

_IO_SET_CONNECT_RET(ctp, _IO_CONNECT_RET_LINK);
len = strlen(newpath) + 1;

msg->link_reply.eflag = msg->connect.eflag;
msg->link_reply.nentries = 0;
msg->link_reply.path_len = len;
strcpy((char *)(msg->link_reply + 1), newpath); <----

len += sizeof(msg->link_reply);

return(_RESMGR_PTR(ctp, &msg->link_reply, len));
}

==== END OF QUOTE ====

My question is:

How is the space at the end of msg->link_reply allocated to store the
newpath.
Is it pre-allocated (if so, then how big is it?) or the caller has to
allocate them (then when to free?)

The io_open_t is defined as:

typedef union {
struct _io_connect connect;
struct _io_connect_link_reply link_reply;
struct _io_connect_ftype_reply ftype_reply;
} io_open_t;

and io_connect_link_reply is defined as

struct _io_connect_link_reply {
uint32_t reserved1;

uint16_t path_len;
/*
struct _io_connect_entry server[nentries];
char path[path_len];
or
struct server_info info;
io
?_t msg;
*/
}

I would appreciate any help to understand how this works.

Thanks.
-chang

Chang Im <chim@cisco.com> wrote:

How is the space at the end of msg->link_reply allocated to store the
newpath.
Is it pre-allocated (if so, then how big is it?) or the caller has to
allocate them (then when to free?)

The ‘msg’ union is pointing into the data buffer of your ctp context,
into which the IO* messages are received. The size can be set with
‘msg_max_size’ of the ‘resmgr_attr_t’ when you attach. In practice it
should be at least big enough to hold 2 pathnames (so rename() will
work naively, although I guess any size larger than a ‘io_open_t’ will
work provided you remember to ‘resmgr_msgread()’ the rest of the message
yourself where necessary); the default is about 2620 bytes (I think).
If you’re using the dispatch/thread pool/resmgr support library, then
this buffer is automatically allocated/freed for each thread.