Multiple device resmgr and message_attach

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi,

if I have a multiple device resmgr, lets say ‘/dev/hw0’ and ‘/dev/hw1’, how
can I bind messages received by message_attach() to that specific device
(hw0 or hw1)? How do I get the corresponding resmgr_attr_t structure I
passed to resmgr_attach()?

I know I could use devctl() messages, with some minor disadvantages.

TIA
Peter

2

“Peter Stoeckigt” <stoeckigt.p@stn-atlas.de> wrote:

Hi,

if I have a multiple device resmgr, lets say ‘/dev/hw0’ and ‘/dev/hw1’, how
can I bind messages received by message_attach() to that specific device
(hw0 or hw1)?

With message_attach(), you can’t.

How do I get the corresponding resmgr_attr_t structure I
passed to resmgr_attach()?

With message_attach() I can’t.

But, in the resmgr_iofuncs_t structure, there is a “msg” callback
for handling messages with a type _IO_MSG. This is a “normal” iofuncs
callback, so all of the client → ocb lookup has been done, and your
callback gets passed an ocb. The ocb includes a pointer to the
attribute structure.

resmgr side:
resmgr_iofuncs_t io_funcs;
…
io_funcs.read = my_read_handler;
io_funcs.msg = my_msg_handler;
resmgr_attach(… );

int my_msg_handler( resmgr_context_t *ctp, io_msg_t *msg, RESMGR_OCB_T *ocb)
{
handle message here
MsgReply()
return( _RESMGR_NOREPLY );
}

client side:
struct {
struct _io_msg hdr;
…
} my_msg;

my_msg.hdr.type = _IO_MSG;
my_msg.hdr.combine_len = sizeof( my_msg.hdr );
my_msg.hdr.mgrid = _IOMGR_PRIVATE_BASE;
my_msg.hdr.subtype = your_msg_type;
/* fill in rest of data */

MsgSend( fd, &my_msg, sizeof(my_msg), … );

Basically:
– message_attach() is for non-fd (filename/pathname/device) oriented
messaging, perhaps from an agent process
– _IO_MSG is for out-of-band messaging associated with an fd (device)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

3

This is not an easy problem. The issue is basically that before the POSIX
IO handlers are called by the framework, it looks up the OCB created when
IO_OPEN message is received. I don’t believe an OCB lookup is done when an
IPC message is received before the registered handler is called.

I’m not the quickest when reading code, I forget stuff easily and it’s been
a while since I’ve looked closely at it. But I recall thinking that there
was a way to get that OCB.

There is an interesting function called _resmgr_ocb(). When you handle the
IO_OPEN message, you can use this function to get the OCB created by the
call to iofunc_open_default(), for example, and then store it on the rcvid
as a key. Then when you get a IPC and you get a message_context_t struct,
you can use the rcvid to look up that ocb thus get access to the
iofunc_attr_t struct which I belive you can use to get a reference to the
pathname.

This is one way I 've thought about using it, but haven’t delved deep enough
to know if it will work under all cicumstances.

Comments are welcome
Kevin


“Peter Stöckigt” <stoeckigt.p@stn-atlas.de> wrote in message
news:b6efmq$ea0$1@inn.qnx.com…

Hi,

if I have a multiple device resmgr, lets say ‘/dev/hw0’ and ‘/dev/hw1’,
how
can I bind messages received by message_attach() to that specific device
(hw0 or hw1)? How do I get the corresponding resmgr_attr_t structure I
passed to resmgr_attach()?

I know I could use devctl() messages, with some minor disadvantages.

TIA
Peter

4

Kevin Stallard <kevin@fffflyingrobbbotsss.com> wrote:

This is not an easy problem.

Actually it isn’t hard with the iofuncs.msg approach that I posted.

There is an interesting function called _resmgr_ocb(). When you handle the
IO_OPEN message, you can use this function to get the OCB created by the
call to iofunc_open_default(), for example, and then store it on the rcvid
as a key. Then when you get a IPC and you get a message_context_t struct,
you can use the rcvid to look up that ocb thus get access to the
iofunc_attr_t struct which I belive you can use to get a reference to the
pathname.

Storing/lookup by rcvid will not, in general, work. If two threads in
the same process message you on the same fd, they could (will) have
different rcvids. If one thread in a process messages you about 2
different fds for 2 different devices, they will have the same rcvid.

The information has to be stored/looked up by scoid & coid. ctp->info
has this, ctp->info.coid and ctp->info.scoid.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

heh…I was wondering about that, just never had a chance to try it…

Thanks,
Kevin

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:b6f7fa$h09$1@nntp.qnx.com…

Kevin Stallard <> kevin@fffflyingrobbbotsss.com> > wrote:
This is not an easy problem.

Actually it isn’t hard with the iofuncs.msg approach that I posted.

There is an interesting function called _resmgr_ocb(). When you handle
the
IO_OPEN message, you can use this function to get the OCB created by the
call to iofunc_open_default(), for example, and then store it on the
rcvid
as a key. Then when you get a IPC and you get a message_context_t
struct,
you can use the rcvid to look up that ocb thus get access to the
iofunc_attr_t struct which I belive you can use to get a reference to
the
pathname.

Storing/lookup by rcvid will not, in general, work. If two threads in
the same process message you on the same fd, they could (will) have
different rcvids. If one thread in a process messages you about 2
different fds for 2 different devices, they will have the same rcvid.

The information has to be stored/looked up by scoid & coid. ctp->info
has this, ctp->info.coid and ctp->info.scoid.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

Thanks,

I will try the David’s aproach.

Especially the information that

“message_attach() is for non-fd (filename/pathname/device) oriented
messaging, perhaps from an agent process”

is helpfull.

Regards
Peter