STREAMS - Request For Information

Jeremy G Harris jgh at root.co.uk
Thu Sep 27 19:47:29 AEST 1990


>In article <634 at mlacus.oz>, paulb at mlacus.oz (Paul Bandler) ask about Streams:
> 2.	Timers.  Maybe I've missed something on first reading but I found
> 	no mention of timer services for STREAMS modules/drivers.  How does
> 	a STREAMS module set a timer and get notified of its expiry?

You're allowed to call timeout().  Unfortunately, the manual does not
say what routines you are allowed to specify to be called at expiration.
When I was dealing with this (under UniPlus V.2 and V.3) I assumed that
any of the module internal routines was fair game and, indeed, it seemed
to work.  I can imagine environments in which this would not work, however,
so for maximum portability perhaps one should only ever arrange to be
qenable()d.  It would be more useful to be putq()d, but there aren't enough
arguments :-(

I do think that this is an area in which Streams is lacking.

> 3.	IOCTL.  This provides a facility to send commands to, and receive 
> 	responses from modules/drivers.  Fine.  However IOCTL aren't supposed
> 	to be forwarded over lower multiplexor driver boundaries.  So in
> 	general it appears that you can't use IOCTL for control interfaces
> 	to your modules in case they ever get 'pushed' under a MUX.  Is this
> 	right or have I gone off track?

Well.... Ish.

>	What is to stop me using some module
> 	addressing scheme that I could devise and direct the multiplexor
> 	driver to route the IOCTL message down the right lower stream?

Not a lot, but note that the application programmer thinks he is ioctl()ing
the upper driver, not the lower one.

>	Is the
> 	right approach to always make your "module" an upper multiplexor so
> 	that it can be open once by a "control" user for control commands and
> 	responses directly, and have other 'data path' streams?

Yup, I prefer this approach.  It means that the application opens the
correctly-named device to ioctl().   Also, don't limit yourself to one
"control" stream.  There's no reason to, and the code is cleaner if
you don't.



In article <14099 at hydra.gatech.EDU> gt0178a at prism.gatech.EDU (BURNS,JIM) writes:
>I would like to see responses to his questions posted as well.

Well..... ok.
-- 
Jeremy Harris			jgh at root.co.uk			+44 71 315 6600



More information about the Comp.unix.internals mailing list