dcb@scirtp.UUCP (David C. Bennett) (10/07/85)
Currently under Bell UNIX, data communications for ttys are
uni-directional. For example, once a port is conditioned to send out
data, it can not readily receive data. I am going to fix the ttys to
be bi-directional on our system, but I'm not sure what approach would
be best. I would like to know if you have any thoughts on this
subject. In the future I will post any suggestions and how I
implemented it.
Thanks,
--
David C. Bennett
SCI Systems, Inc.
{decvax, akgua}!mcnc!rti-sel!scirtp!dcbolson@fortune.UUCP (Dave Olson) (10/11/85)
One approach that can be taken to allow bi-directional use of tty lines is to have 2 minor #'s for each physical port. This is the approach that was take at Fortune Systems. If one has a tty port with maj/min of 8/0, then the device with 8/128 would be the corresponding outgoing port. A few new ioctl's were added to allow you to say that the outgoing line should not complete open till carrier is up, the same for the incoming line, or neither. When either minor # is opened, attempts to open the other mode fail with EBUSY. The changes that need to made are relatively minor (but are unfortunately proprietary code, so I can't post them). Dave Olson Fortune Systems
guy@sun.uucp (Guy Harris) (10/13/85)
> Currently under Bell UNIX, data communications for ttys are > uni-directional. For example, once a port is conditioned to send out > data, it can not readily receive data. What? When I log into a UNIX system, I can type at it at the same time it's typing at me. What do you mean by "conditioned to send out data"? You can't have one process blocked on a "read" on that port and doing a "write" on the port at the same time on any current UNIX. Programs like "cu" usually work by having two processes, one doing the reads and one doing the writes. Guy Harris
chris@umcp-cs.UUCP (Chris Torek) (10/13/85)
> One approach that can be taken to allow bi-directional use > of tty lines is to have 2 minor #'s for each physical port. We use two major device numbers, but the basic idea is the same. > ... attempts to open the other mode fail with EBUSY. Personally, I think that our approach (making normal `incoming' opens simply suspend until the outgoing call has completed) is better. > The changes that need to made are relatively minor (but are > unfortunately proprietary code, so I can't post them). But I can post ours, and I have done so in the past. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/14/85)
> > Currently under Bell UNIX, data communications for ttys are > > uni-directional. For example, once a port is conditioned to send out > > data, it can not readily receive data. > > What? When I log into a UNIX system, I can type at it at the same time it's > typing at me. What do you mean by "conditioned to send out data"? You > can't have one process blocked on a "read" on that port and doing a "write" > on the port at the same time on any current UNIX. Programs like "cu" > usually work by having two processes, one doing the reads and one doing the > writes. I couldn't figure this out either. Finally I decided they must be talking about setting different terminal modes (stty) for the outgoing and incoming data channels. If not, I wish they'd explain.
mikel@codas.UUCP (Mikel Manitius) (10/19/85)
> Currently under Bell UNIX, data communications for ttys are > uni-directional. For example, once a port is conditioned to send out > data, it can not readily receive data. Hmph. Obviously you have never heard of the terms "Full Duplex" and typeahead. -- Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel
bruce@stride.UUCP (Bruce Robertson) (10/22/85)
In article <5647@fortune.UUCP> olson@fortune.UUCP (Dave olson) writes: >One approach that can be taken to allow bi-directional use >of tty lines is to have 2 minor #'s for each physical port. > >This is the approach that was take at Fortune Systems. > > The changes that need to made are relatively >minor (but are unfortunately proprietary code, so I can't post >them). Well, Stride Micro has done essentially the same thing, and since we don't consider the code to be proprietary, I'll be glad to post the code if there is enough demand. -- Bruce Robertson UUCP: cbosgd!utah-cs!utah-gr!stride!bruce