mis-feature of the 4.1/4.2 dh/dm driver?

[Terry Countryman]

Recently I was working on a version of the 4.2 'login' program that
implements a call-back protocol (We don't have measured service, but
we do have some people working long distance).  In implementing
the hangup and call-back section, I noticed a bug or mis-feature
of the soft-carrier capability of the dh/dm driver.  What I had planned
to do was:

	1. set soft carrier on the tty line;
	2. drop DTR (and CD) with the TIOCCDTR ioctl;
	3. sleep a while to let the line settle;
	4. set DTR with the TIOCSDTR ioctl;
	5. sleep a while;
	6. call the user back;
	7. clear soft carrier, so that CD works properly;

This almost works; but when DTR (and thus CD) is dropped it causes a dm
interrupt to change the hardware carrier state.  In the dmintr routine
the soft carrier flag for the line is checked, and if set it does not
send the SIGHUP or SIGCONT signals nor does it do some other status
clearing operations.  Then it unconditionally clears the TS_CARR_ON
state kept in the tp->t_state field even though soft carrier is set for
for the line.  When I tried to write to the modem to call-back,
the higher level tty routines make sure to check
for TS_CARR_ON being set before doing any I/O on the tty line.

Is this just an incomplete implementation of the soft carrier
capability, or is there some reason that TS_CARR_ON should always
shadow the hardware carrier signal?

I got around the mis-feature by opening and closing the tty line
between steps 5 and 6; the driver checks the soft carrier on
opens and sets the TS_CARR_ON flag for the line.

The dmf and dz drivers implement only part of the soft carrier
capability present in the dh/dm driver.  Has anybody worked on this
feature?

	Terry Countryman
	...!{akgua,gatech,ihnp4,mcnc,ncsu}!msdc!terry