I’m having trouble figuring out how to have a (read and write) devctl
handler in a resource
manager do a delayed reply to the client. For other io calls (read,etc.),
you can just
store the rcvid and respond, but it seems like devctl is expecting a funkier
message with
all the header stuff in it. Is that documented anywhere? Is the header
format and size
“stable” or will my code break with the next release? Do I need to use the
devctl
macros later on to format the reply message properly? Is the ctp (required
for the macros
to work) persistent until the reply occurs or do I have to copy them for my
later use?
Thanks,
Arthur
“Arthur Q” <3_arthur@my-deja.com> wrote in message
news:8tmn3j$3ok$1@inn.qnx.com…
I’m having trouble figuring out how to have a (read and write) devctl
handler in a resource
manager do a delayed reply to the client. For other io calls (read,etc.),
you can just
store the rcvid and respond, but it seems like devctl is expecting a
funkier
message with
all the header stuff in it. Is that documented anywhere? Is the header
format and size
“stable” or will my code break with the next release? Do I need to use
the
devctl
macros later on to format the reply message properly? Is the ctp
(required
for the macros
to work) persistent until the reply occurs or do I have to copy them for
my
later use?
Thanks,
Arthur
Update: I tried using a MsgReplyv for returning my data with a hand-
built _io_devctl_reply struct prepended to it. The data seems to get
back to the client ok, but the devctl call returns error 312, “server fault
on message pass.” Any ideas what the problem might be?
-Arthur
“Arthur Q” <3_arthur@my-deja.com> wrote in message
news:8tms3m$9e2$1@inn.qnx.com…
“Arthur Q” <> 3_arthur@my-deja.com> > wrote in message
news:8tmn3j$3ok$> 1@inn.qnx.com> …
I’m having trouble figuring out how to have a (read and write) devctl
handler in a resource
manager do a delayed reply to the client. For other io calls
(read,etc.),
you can just
store the rcvid and respond, but it seems like devctl is expecting a
funkier
message with
all the header stuff in it. Is that documented anywhere? Is the header
format and size
“stable” or will my code break with the next release? Do I need to use
the
devctl
macros later on to format the reply message properly? Is the ctp
(required
for the macros
to work) persistent until the reply occurs or do I have to copy them
for
my
later use?
Thanks,
Arthur
Update: I tried using a MsgReplyv for returning my data with a hand-
built _io_devctl_reply struct prepended to it. The data seems to get
back to the client ok, but the devctl call returns error 312, “server
fault
on message pass.” Any ideas what the problem might be?
-Arthur
Update take II: The server fault was due to my stupidity, so my handbuilt
reply works now. I’m still curious if this is a proper way to do this or if
it will come back to haunt (ahem) me later.
-Arthur
Arthur Q <3_arthur@my-deja.com> wrote:
: “Arthur Q” <3_arthur@my-deja.com> wrote in message
: news:8tms3m$9e2$1@inn.qnx.com…
:> “Arthur Q” <3_arthur@my-deja.com> wrote in message
:> news:8tmn3j$3ok$1@inn.qnx.com…
:> > I’m having trouble figuring out how to have a (read and write) devctl
:> > handler in a resource
:> > manager do a delayed reply to the client. For other io calls
: (read,etc.),
:> > you can just
:> > store the rcvid and respond, but it seems like devctl is expecting a
:> funkier
:> > message with
:> > all the header stuff in it. Is that documented anywhere? Is the header
:> > format and size
:> > “stable” or will my code break with the next release? Do I need to use
:> the
:> > devctl
:> > macros later on to format the reply message properly? Is the ctp
:> (required
:> > for the macros
:> > to work) persistent until the reply occurs or do I have to copy them
: for
:> my
:> > later use?
:> >
:> > Thanks,
:> >
:> > Arthur
:>
:> Update: I tried using a MsgReplyv for returning my data with a hand-
:> built _io_devctl_reply struct prepended to it. The data seems to get
:> back to the client ok, but the devctl call returns error 312, “server
: fault
:> on message pass.” Any ideas what the problem might be?
:>
:> -Arthur
: Update take II: The server fault was due to my stupidity, so my handbuilt
: reply works now. I’m still curious if this is a proper way to do this or if
: it will come back to haunt (ahem) me later.
Nope this shouldn’t come back to haunt you. Our message
headers are defined in <sys/iomsg.h> and will forever
(or for a really really long time) be defined as you
see them. Yes you will see that the way that the
messages work is that most of them are a union of
an incoming message and an outgoing message. For the
devctl() you need to provide the reply (whenever you
decide to do this) as stated. ie
[struct _io_devctl_reply w/ nbytes filled in]
[data[nbytes]]
Of course the easiest way to do this is a two part
iov with the header in the first part and your
data in the second.
In terms of delayed reply. Return from the devctl()
handler with _RESMGR_NOREPLY and then you will want
to store the rcvid (along with potentially other
information) to use in the reply. Hanging on the
the ctp is no good since this context will get
re-used the next time the thread does a MsgReceive().
You can possibly hang on to the ocb and the attribute
since those are within your control. Which macros
are you wanting to use? If you are doing a delayed
reply then most of the macros won’t apply and you
will have to cook up the message for reply by hand
and use MsgReplyX()/MsgWriteX() family of functions.
Thomas
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf