paulb@mlacus.oz (Paul Bandler) (09/24/90)
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
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/25/90)
in article <634@mlacus.oz>, paulb@mlacus.oz (Paul Bandler) says: > 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 Internet: gt0178a@prism.gatech.edu
jgh@root.co.uk (Jeremy G Harris) (09/27/90)
>In article <634@mlacus.oz>, paulb@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@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: >I would like to see responses to his questions posted as well. Well..... ok. -- Jeremy Harris jgh@root.co.uk +44 71 315 6600