Text File

Aucbvax.5472 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Mon Dec 14 14:19:48 1981 ^D on output to terminals >From decvax!ittvax!swatt@Berkeley Mon Dec 14 14:17:43 1981

Steve Bellovin's remarks are applicable to more than one random device hooked up to tty ports. We have a 2780 protocol converter that accepts ^D from the asynchronous side to indicate (by gawd) end of transmission, and turns the line around to allow input from the synchronous side. Now since this is a machine-machine communication path, high speeds, and therefore flow control, are very desirable.

I have thought of several ways around this. One is obviously to change the mode of the driver for the instant it takes to send the ^D. One is as Steve Suggested, ~nother driver status bit. The last one, which I prefer, would be to have the driver check not for "EOT", but for "tun.t_eofc" (or whatever the name is). By accident or design the driver does this now with the XON/XOFF characters ("tun.t_startc" and "tun.t_stopc"), so if you change them, you change what the driver expects/sends for flow control when in TANDEM mode.

I don't know which terminals actually do hang up on ^D, and if I did, I would immediately add them to the list of un-favorite peripherals. In any case, the need for flow control and a transmission path for all 7 bit characters is clear.

BTW, has anybody extensively used the TANDEM mode while in normal cooked (not RAW or CBREAK) mode. The last time I tried it, there was a subtle bug that cropped up if you sent relatively long average lines.

>From looking at the 4.1bsd drivers, it seems like the bug is still there. The following is a description of the problem and a SUGGESTED fix.

NB: I have not installed or tested these changes. I would be interested to hear if anyone can confirm or deny the existence of the problem, or could test out the suggested fix. I get almost zilch in the way of kernel test time, so I won't get around to this one until it bites us.

- Alan S. Watt (decvax!ittvax!swatt)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: As they stand now, the tty drivers (old and new) can only safely use TANDEM mode if also in either RAW or CBREAK mode. The reason is that the XOFF character is sent at interrupt time from ttyinput(), but the XON character is sent from program level in canon().

The XOFF is triggered when the input queue is TTYHOG/2, and the XON is sent when input drops below TTYHOG/5, where "TTYHOG" is 255. If you are in cooked mode and sending lines > 51 characters long, a hang will occur if the XOFF is transmitted after 51 non-wakeup characters have been transmitted on the current line and input is stopped before a wakeup character is read. Try receiving a bunch of 80 character lines and you will for sure hang.

# enclosed fix: : '/sys/dev/tty.c' cp /sys/dev/tty.c /tmp/upd.$.tmp ; chmod +w /tmp/upd.$.tmp ed - /tmp/upd.$.tmp <<\!XXFUNNYXX * /* CURRENT IFF: 145C FURTHER BLOCK INPUT> threshold AND input is available to user program */ #define CookedMode(X) (((X)->t_flags&(RAW|CBREAK))==0) #define InputReady(X) ((X)->t_delct>0 || !CookedMode(X)) if (x >= TTYHOG/2 && InputReady(tp) ) {

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.