tanya@adds.newyork.NCR.COM (Tanya Katz) (07/01/89)
I am writing a streams multiplexer driver that monitors
input from several (many) ttys, packets the data, and routes the packeted
input to one single process. On output, the M_DATA field will
be encoded with the port number, sent through the multiplexor, and
routed to the proper tty.
All the examples I have seen have many user processes
connected to a single tty port, or are connected 1-to-1.
I have not seen examples of the architecture we are interested in, where
one process is reading from / writing to many ttys and a multiplexor
is handling this data.
A central issue in this design is minimizing the use of
file descriptors. We would prefer having only one multiplexor device,
and link multiple tty streams to it, but the streams data structures
design seem to indicate that we must open a separate minor multiplexor
device for each tty stream & link these in separately
in order to properly initialize the lower write queue of the linkblk
structure.
Is there a way to open the multiplexor only once, and to use
this open multiplexor fd to link in each open tty stream and
properly maintain the l_qbot pointer in the linkblk structure for
each member of the multiplexor array?
In other words, what I am asking is: If the driver is opened
once (dev 0 ) and only the first array member is initialized, can my upper
write put routine link this device with each open tty (separate ioctl
calls of course) and initialize the multiplexor array with the correct
streams l_qbot/write pointer & mux-id?
I would appreciate any information from others who have written
multiplexors on how such a beast might be designed, as well
as any practical advice from those who have "been there."
Thanks,
Tanya
------------------------------------------------------------------------------
### ###### ###### ##### Tanya Katz (516) 231-5400 x430
# # # # # # #
# # # # # # ##### ...uunet!ncrlnk!adds!tanya
####### # # # # # tanya.katz@adds.newyork.ncr.com
# # ###### ###### #####
Applied Digital Data Systems, Inc. 100 Marcus Blvd., Hauppauge, NY 11788
------------------------------------------------------------------------------jgh@unisoft.UUCP (Jeremy Harris) (07/04/89)
In article <1116@adds.newyork.NCR.COM> tanya@adds.newyork.NCR.COM (Tanya Katz) writes: > [ asking how to write a bottom-multiplexing streams driver ] > > I am writing a streams multiplexer driver that monitors >input from several (many) ttys, packets the data, and routes the packeted >input to one single process. On output, the M_DATA field will >be encoded with the port number, sent through the multiplexor, and >routed to the proper tty. > >A central issue [..] is minimizing the use of file descriptors [..] >the streams data structures >design seem to indicate that we must open a separate minor multiplexor >device for each tty stream & link these in separately >in order to properly initialize the lower write queue of the linkblk >structure. No problem here; you only need the one stream into the top of the multiplexer. Every time you link a new tty stream into the bottom of the mux, you (with your mux hat on) get told the lower write queue to use for writing to that stream. All you have to do is remember that in association with some criteria for routing through the multiplexer (in your case this can probably be the l_index value); it doesn't matter that all the I_LINKs are issued from a single top stream. You mentioned using an array for remembering these things. How about a linked list using dynamically allocated structures? Use allocb() for the allocator. You then haven't the same hard limit on number of channels in use. Since the data travelling the multiplexed stream carries control information as well as pure data, consider using M_PROTO messages and putmsg()/getmsg() rather than M_DATA. Any naive process which tries to read()/write() by some mistake then finds out the error of its ways rapidly. Hope this helps, and happy Streaming. Jeremy PS: my credentials: internet protocols as streams modules; about eight modules and drivers, two of which were bottom-multiplexers. Took about two man-years. And it's far more maintainable than 4.3 code. - Jeremy Harris UniSoft Ltd. 8/9 Hayne St, London EC1A 9HH. England jgh@root44.co.uk (briefly on loan to UniSoft Corp.)