Text File

Aucbvax.5625 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Sun Dec 27 18:16:33 1981

>From decvax!cwruecmp!ordy@Berkeley Sun Dec 27 18:01:28 1981 ~s LMDMBUF Please excuse this rather long message:

We are interested in some comments on a particular aspect of the tty driver(s) for 4.1 BSB. We assume this also effects 2.8 BSD, and possibly straight V7.

Rather than purchase DEC lp-11 interfaces for our printers/plotters we like to drive such devices from DZ-11's and DH-11's. Under 4.1 BSD there appears to be a very nice mechanism to do this. When we want to use such a device, through such an interface, we (user program):

1) set LMDMBUF with an ioctl. This should cause the output stream to be flow controlled with the hardware carrier. Note that on our 4.1 BSD release only the DH-11 driver supported this. I added it to the DZ-11 driver.

2) set LNOHANG with an ioctl. This inhibits hangup signals on carrier loss, which is now the flow control input.

3) set TIOCEXCL to make the device single user, for the obvious reasons.

4) there may be an stty or two to set up baud rate and other things like that.

After doing these, the DH or DZ line performs quite nicely, and in the case of devices with high character rates, like a 600 LPM printer, the added bonus of DMA output on the DH-11 really reduces the load on the system.

The problems come in when you want to close the device. There are two flavors of problems, depending on which line discipline you are using (OLD or NEW). Let us explore each.

1) OLD (standard) line discipline. In this case, when the driver (DH or DZ) close routine is called, it first calls the close routine in the linesw table. For the old discipline, this is 'nulldev' (!!!). After some uninteresting things, DTR is turned off (possibly a big mistake) and ttyclose is called.

2) NEW line discipline. The driver (DH or DZ) calls the linesw close routine, which for this discipline is 'ntyclose'. This guy consists of a call to wflushtty. In wflushtty, we have the test:

while (tp->t_outq.c_cc && tp->t_state & CARR_ON)

The intent of this while is to keep poking the start routine until all of the characters are out. Note that in all cases, it is possible to be in the close routine while characters are still draining. Problem is, if LMDMBUF is set, the CARR_ON bit is not static, but changes with carrier, that is the flow control. As a result, this while can fail, even though valid characters still need to be pumped out. After this flushtty is called, which throws away whatever is left (seems undesirable). Once back in the device driver close, things are pretty much as in the OLD discipline case.

Without changing the system code, our solution is to sleep several seconds before calling close from the user program, to give the output time to get out alive. Without this fix, the tail of a transmission is garbled/missing.

Our questions/comments are:

Why does the old line discipline have nulldev for a close entry. Seems like some intelligent things could be done there. If nothing else, it means LMDMBUF will never work.

The while described above in wflushtty should be aware of LMDMBUF, and that CARR_ON not being present is not necessarily a sign of problems (if LMDMBUF is in use).

Before we change our system, we would like to make sure we are not crazy, and are correctly interpreting how LMDMBUF should work. If only wflushtty is changed, LMDMBUF will only work with the new discipline.

Any comments on this would be quite helpful, thanks for listening.

Greg Ordy

----------------------------------------------------------------- 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.