STREAMS - Request For Information

STREAMS - Request For Information

Post by Paul Bandl » Tue, 25 Sep 1990 17:16:30



I am learning the System V STREAMS facilities from the documentation provided
with the OS (SVR3).  I would appreciate assistance with any of the following
questions:

1.      Are there any good books on the subject other than the STREAMS
        programmers guide?

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?

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?  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?  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?

4.      Can anyone provide me with an example of a "provider interface".  I'd
        prefer the Transport Provider Interface (TPI) so that I can see how
        it maps to the TLI, but any would be most welcome.

5.      Are there any Public Domain examples of streams module/driver
        implementations available?

Please email responses as news takes several days to trickle across the Pacific.

Thanks in anticipation,

Paul Bandler
ACUS - Australian Centre For Unisys Software
FAX: +61-3-267-4692
TEL: +61-3-823-1037

 
 
 

STREAMS - Request For Information

Post by BURNS,J » Wed, 26 Sep 1990 19:56:24



Quote:> I am learning the System V STREAMS facilities from the documentation provided
> with the OS (SVR3).  I would appreciate assistance with any of the following
> questions:
> Please email responses as news takes several days to trickle across the Pacific.

I would like to see responses to his questions posted as well.

--
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a


 
 
 

STREAMS - Request For Information

Post by Jeremy G Harr » Fri, 28 Sep 1990 18:47:29



> 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.

Quote:> 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.

Quote:>    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.

Quote:>    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.


>I would like to see responses to his questions posted as well.

Well..... ok.
--

 
 
 

1. Streams information / Book

I am looking for a good book, or FAQ/webpage on STREAMS filters specifically
with Solaris... Most importantly some good information on pfmod and how
to get the in-kernel packet filter to work correctly.

                Thanks in Advance!

                         Dave Smith.

2. rawhide, KDE-pre rpms + glibc ?

3. Information about SCO Unix STREAMS network driver?

4. Replacing 8 GB IDE drive on Ultra 5 with larger IDE drive (possible to clone or duplicate drives?)

5. UNIX STREAMS Information please

6. Start a programm and get it's pid

7. STREAMS Failures information

8. PCMCIA Network Adapter

9. POST requests missing POST input stream

10. Streams Bind request format to /dev/ip

11. STREAMS Driver Design Help - Opinions requested

12. request for sample streams module code

13. Request for Computer Information...