Date: Sun, 27 Feb 2000 17:48:39 +0100
From: Vojtech Pavlik <vojtech@suse.cz>
I'm mailing you, as the author of the tty code under Linux, with
a question about how to do hangup correctly. I'm writing an USB modem
driver. The USB hardware emulates a PC serial port and a modem connected
to it.
The hangup code is a big mess, right now, so this gets tricky. I
apologize for that; I want to clean it up after 2.4, but it's going to
require some massive incompatible changes to all of the tty drivers.
Now, what I'd like to know is what to do exacly on a DCD signal drop to
correctly signal the application the line was disconnected (eg. when
running pppd and the modem looses carrier.)
I'm doing it now via tty_hangup(). What's odd is that most other serial
drivers have their own BH which they schedule to run tty_hangup(). This
seems nonsensical to me, because tty_hangup() schedules a task queue,
which in turn runs tty_do_hangup(). Why the BH? Relict historical
code?
The issue is that the tty_hangup code can get called through two paths.
It can get called by the device drivers via tty_hangup(), and it can
get called from as a result of a vhangup() system call. The problem is
that you can run into race conditions where getty() calls vhangup() at
the same time as DCD drops, and if the device driver calls tty_hangup()
out of the interrupt handler, nasty races can happen. By calling
tty_hangup out of a BH, it avoids this race condition.
Now the real problem - in minicom when the DCD signal drops, the CLOCAL
flag isn't set and thus my code calls tty_hangup() and kills any further
communication with modem. Not minicom, though. What exact conditions
have to be met to call tty_hangup()? For normal serial lines this
doesn't happen with minicom ...
You're doing the right thing. If DCD drops, and CLOCAL isn't set,
calling tty_hangup() is the right thing. There are no other conditions.
If the application doesn't want this behaviour, it should make sure
CLOCAL is set. I don't have the sources to minicom handy at the moment,
so I'm not sure what else it may be doing; it may be catching SIGHUP or
noticing the error from calling read or write, and then reopening the
serial port.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:22 EST