Messages in this thread | | | Date | Tue, 29 Feb 2000 13:57:08 -0500 | Subject | Re: How to do hangup? | From | tytso@mit ... |
| |
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/
| |