Garrett D'Amore wrote:
Zimmer Sébastien wrote:
Hi community,
I was wondering about handling of ioctl on multiplexer. The small
architecture I have in mind is the following: StreamDriver <-> Module
<-> multiplexer. The driver is opened and the module is I_PUSH'ed on
it, then the muxer is opened and I_LINK'ed to the module. In another
process, I reopen the driver and try to send an ioctl request. It
fails and the encountered error is the following: "[Errno 22] Invalid
argument".
I already checked that the ioctl is correctly handled when the muxer
is not linked. I add a lot of debug logging and apparently the driver
does *not* receive a mblk of type M_IOCTL. So the first question is:
"why don't I receive a mblk of type M_IOCTL when the muxer is linked
?". Neither the muxer, nor the module, nor the driver ... is it
possible the stream framework is rejecting any ioctl for the linked
stream ?
The q_next pointers from above streams end at the mux. In other words,
you can't just putnext() the message down. If you want to pass M_IOCTL
messages down lower streams, you need to keep track of the lower queues
to find which queue(s) to pass the message down to. Also, the mux acts
as a stream head to the lower streams, so you'll have to handle
M_IOCACK/M_IOCNAK in the lower part of the mux and figure out how to
communicate the ack/nak to the appropriate upper stream. All in all,
you're better off opening the device, pushing the module, sending the
ioctl(s), and then linking with the mux. You can take a look at the
consms driver which acts as a mux and allows mulitple lower streams to
be linked and which does M_IOCTL handling for those stream.
Specifically, start with consms_mux_disp_ioctl() in consms.c
I also though of a work-around for this problem. Maybe I can open the
muxer instead of the driver and the muxer would forward the ioctl to
the driver. However the forwarding wasn't mention in the stream
framework pdf, so I didn't implement it. I also fail to find any
reference to such a technique in the source of opensolaris, that's
why I'm asking: "Should the muxer forward the ioctl downstream ?". I
don't think so as it a driver (it should drop unknown ioctl) but it's
a special driver, so I'm a bit perplex here :)
I think that depends on the mux driver. mux drivers are weird. Some
times it can pass down an ioctl, but then it also needs to be prepared
to pass up the reply. And if the mux sends an ioctl down multiple
paths, it has to resolve multiple responses.
I've done work like this in the past... its not hard, but its not
trivial either. There are lots of edge cases.
Best bet is to avoid having to pass an ioctl thru a mux, if you have a
choice.
Last thing I tested. I open the driver and push the module on it. In
another process, I reopen the driver, push the module and link the
muxer. Then I used the first handle to the driver and send the ioctl
request and it works. So, driver and module ioctl handling are
working but it doesn't work anymore once I linked the muxer and
reopen the driver after the I_LINK.
I think we need more information about the mux driver you're working
with, and the anticipated plumbing. It could a bug in the the bottom
driver, as well (perhaps doing qreply to the wrong queue?)
-- Garrett
Thanks for any clue you can provide me with,
Sebastien
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
