dennis@rlgvax.UUCP (Dennis Bednar) (04/11/86)
What does a tty port *with* modem control mean, and
what does a tty port *without* modem control mean?
--
-Dennis Bednar
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCProb@ptsfb.UUCP (Rob Bernardo) (04/14/86)
In article <979@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis Bednar) writes: >What does a tty port *with* modem control mean, and >what does a tty port *without* modem control mean? "Modem control" means that the device to which the port is connected must indicate its ready state before certain i/o is allowed. If an rs-232 port has modem control, an open(2) on the port will block until the outboard device "asserts" data carrier detect (DCD), that is, until it puts a high voltage on on pin 8 of the rs-232 cable. However, if your open(2) uses the flag O_NDELAY, the open(2) will return without waiting for DCD to come high. BTW, this can be found on the manual page for open(2). Without modem control, the port can be opened, read from and written to without DCD being asserted. Furthermore, my experience on one system is that with modem control, if DCD is dropped after the open, and read(2)s or write(2)s to the port will block until DCD is restored. I suspect that if the port was opened with the O_NDELAY flag, read(2)s and write(2) will not block, but I don't know for sure since the system on which I have noticed the blocking of reading and writing has a bug that renders the O_NDELAY flag nonfunctional. The manual page for read(2) says something similar to this, and the manual page for write(2) says nothing about the effects of O_NDELAY on write(2)s to tty ports. Maybe someone else can detail how read(2) and write(2) are *supposed* to be affected of the O_NDELAY flag. Rob Bernardo, San Ramon, CA (415) 823-2417 {ihnp4|dual|qantel}!ptsfa!rob Pacific * Bell
ka@hropus.UUCP (Kenneth Almquist) (04/16/86)
Furthermore, my experience on one system is that with modem control, if DCD is dropped after the open, and read(2)s or write(2)s to the port will block until DCD is restored. In SysV, read is supposed to return zero after carrier is dropped, according to the termio manual page. I don't think that the manual says what write is supposed to do in this situation; the device drivers that I have experimented with all return zero when this happens (or a short count if carrier drops in the middle of a write). Maybe someone else can detail how read(2) and write(2) are *supposed* to be affected of the O_NDELAY flag. In SysV, reads on a tty should not roadblock if data is not available; they should return 0 instead. It is true that the UNIX manual says nothing about the effects of the O_NDELAY flag on writes to a tty; I believe that this om- ission was an intentional one, indicating that the O_NDELAY flag should have no effect on writes to a tty. The preceding paragraph applies only to System V. 4.2 BSD also has no delay I/O, but under BSD read returns an error indication rather than zero to in- dicate that no data is available. I believe that the Berkeley approach is better (since it avoids the confusion between "no data available" and "end of file"), but it does mean that System V and BSD are incompatible in this area. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
jhc@mtune.UUCP (Jonathan Clark) (04/24/86)
Having come late to this question (our news feed having been down for a few days), but being slightly familiar with the USG tty driver, I can comment that if you read the termio man page many things are possible. As I read the VAX 5.0 code the following scenario will occur every time: dcd is down throughout all this proc 1 opens line with O_NDELAY proc 1 sets CLOCAL (which I read as 'ignore DCD') proc 1 does a write and blocks proc 2 does a !O_NDELAY open (which succeeds) proc 2 does a write which succeeds pric 1 is still blocked... Apparently this is fixed in 3b2 SVR2. I'm very close to fixing it for the UNIX PC. But the set of interactions inside the tty driver is heavily religious. Informed comments are welcomed. -- Jonathan Clark [NAC]!mtune!jhc My walk has become rather more silly lately.