No subject

[utzoo!decvax!ucbvax!unix-wizards]

>From decvax!cwruecmp!ordy at 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