terry@msdc.UUCP (Terry Countryman) (09/27/85)
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