USG (maybe others?) bug in tty open/close

[geoff at callan.UUCP]

We have a situation in our system startup which works something like this
(names have been changed to protect the innocent):

	/etc/program </dev/tty77 >/dev/tty7 2>&1 &
	echo 'message' >/dev/tty77

The timing of this happened to work out as follows:

	'echo' opens /dev/tty77
	'program' starts the open on /dev/tty77
	'echo' closes /dev/tty77
	'program' finishes the open on /dev/tty77

(This is the actual sequence of messages from the tty77 driver when debugging
is turned on).

The reason tty77's open is interrupted by the close is that the driver in
'tt0.c' or 'tt1.c' goes to sleep for a bit during the open.  This gives the
close time to enter and run.  Unfortunately, the open routine allocates the
receive buffer (t_rbuf) *BEFORE* going to sleep, and the close routine
unhelpfully deallocates it!  The net result is that, when all has finished,
'program' has no allocated t_rbuf, and thus cannot do reads on /dev/tty77.
Most embarrassing, especially if your system won't run if 'program' won't
(which happened to be true in this particular case).

The workaround (until I fix the bug properly) was simple:  I just added a
'sleep 10' before the echo.  Ugly, to be sure, but it worked.

My feeling is that the close should never get called, since closes are only
supposed to happen on the LAST close of the device, and the in-progress open
should (in my opinion) mark the device open.  But if I modify the kernel to
mark the device open before the 'cdevsw' open routine is called, I am afraid
of getting into unpleasant ramifications if the open routine rejects the open
(e.g., because of a nonexistent device).  Furthermore, it seems like I am
still going to get into trouble because the kernel considers every major/minor
combination to be different, but my driver may see them as the same (e.g., the
no-rewind bit on a tape drive).

The major/minor problem could be fixed by putting the fix into the 'tty77'
driver, but then I would have to fix every tty driver, and the problem might
still crop up in non-tty devices if they sleep during opens.  Fixing it in
'tt0.c' or 'tt1.c' (or both, if you run both) solves the first objection but
not the second.

Has anyone else encountered and fixed this problem?  Does anybody have advice
on the best way to handle it?  Please reply by mail and I will summarize to
the net.
-- 

	Geoff Kuenning
	Callan Data Systems
	...!ihnp4!wlbr!callan!geoff