Re: Bug in serial line hangup code ?
Peter Fox (fox@roestock.demon.co.uk)
Tue, 7 May 96 07:44 BST
> Date: Mon, 6 May 1996 14:16:51 -0400
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>
> From: Peter Fox <fox@roestock.demon.co.uk>
> Date: Sun, 5 May 1996 13:45:11 GMT
>
> ppp enables hangup, and on hangup closes the port. The serial driver
> sets info.count to 0 on hangup, even though my program still has the
> port open. As my program watches info.count to determine if another
> process has the line is open, this is a bit of a problem.
>
> This is the way the serial driver is *designed*. Once a hangup has
> occurred, programs do not logically have the port "open". Access to the
> file descriptors has been revoked, and so they no longer can read or
> write to the serial port.
>
> Furthermore, the design goal is upon hangup to shutdown the serial port
> entirely. This guarantees that upon a vhangup(), the modem line is
> dropped. Your patches change this.
>
> How about including this lot before 2.0 ?
>
> Your patches could potentially break all manner of programs that assume
> the current behavior. I am willing to revisit the design of the entire
> tty hangup behavior, but this will involve changing more than just the
> serial driver --- and just before 2.0 is not a good time to do this.
I suspected as much !
On the other hand, it seems to have fixed all those annoying little
messages from pppd: tcgetattr: I/O error, because my monitor process
prevents the port being shutdown on hangup. (pppd-2.2.0c)
Obviously, it is meaningless for two processes to have the same port
open for I/O, which is why there are lockfiles etc, but
I've certainly found the ability to monitor the port useful, so if there
is a way to let a process do ioctls etc, immune from hangups etc, then
please do revisit the hangup code.
At the moment my program drops DTR when it discovers it's the only one
with the port open, to make sure the modem resets.
A few observations, on why my monitor program doesn't simply reopen
the port when it gets I/O errors:
a) I wanted it to work on stdin. (This is not a big issue, and I don't
use it this way)
b) My program resets DTR when it opens the port to prevent the modem
thinking there is a process listening. I can envisage race conditions
between my monitor program and (say) mgetty if they are both opening
the port (in fact, if mgetty gets in first it's possible that the
open will fail with the port busy).
c) Events may be lost while the port is being reopened.
Peter.