bad@flatlin.ka.sub.org (Christoph Badura) writes:

> 
> >* Fixing a bug for this snapshot has introduced an incompatibility
> >with kermit.  Basically, if we have carrier detection enabled and we
> >lose DCD, then we drop DTR.
> 
> Why?  What has the loss of Data Carrier Detect to do with the state of
> Data Terminal Ready?  Why isn't DTR simply asserted as long as the
> port is open?

Honestly, I have no idea.  That's just how it was done before.  It
seems to me that in the usual case (e.g. getty, a shell, pppd,
whatever) the loss of DCD is going to cause all the processes holding
the port open to die, so it will get closed and DTR will be dropped
anyway.  In the case where something like kermit is holding it open,
you probably don't want DTR to be dropped automatically.

> >  If a program wants to continue using the
> >port, it must either close and reopen it, or set CLOCAL mode and then
> >do a TIOCSDTR.  kermit tries to continue using the port after just
> >setting CLOCAL, and thus fails if the device on the other end is
> >waiting for carrier.  It's unclear whether or not we should be
> >clearing DTR in this case, but that seems to be what the majority of
> >existing systems do.
> 
> Charles, how did you probe "the majority of existing systems."  I, for
> one, haven't seen that behaviour on any of the Unix systems I worked
> on.

I had little birdies look at the source for me.  I can tell you that
all of 4.4BSD-Lite2, SunOS 4.1.1, BS-DOS 2.1, and Solaris 2.3 do this,
as well as some other systems that I can't mention.