[driver-discuss] Ioctl with multiplexers.

[max at bruningsystems.com]

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
>> driver-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
> _______________________________________________
> driver-discuss mailing list
> driver-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>