Date: Mon, 2 Jan 95 17:34:45 MST From: terry@cs.weber.edu (Terry Lambert) To: jeff@tenforwd.wiz.com (Jeff Haynes) Cc: freebsd-questions@freebsd.org Subject: Re: Serial port questions Message-ID: <9501030034.AA02451@cs.weber.edu> In-Reply-To: <199501021738.LAA03256@tenforwd.wiz.com> from "Jeff Haynes" at Jan 2, 95 11:38:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I am having a problem getting slattach to work while mgetty is running. > slattach will dial out, but then mgetty seems to take over. This seems > to be a locking problem. Darn right! mgetty should be "locked out" of having its open complete until DCD is present! Because mgetty violates the rules, you get bogus behaviour. The SCO uugetty used to violate the rules as well. It was hacked to respect lock files (and to create them) and then retry its open something like once every 20 seconds until the lock file went away. > UUCP and mgetty work fine together, so I think this is a problem with > how slattach locks the line. I had no problems in 1.1.5.1. I am running > 2.0 now. Yes and no; mgetty's open of the line not hanging for DCD to become present is unutterably bogus. > slattach, mgetty and UUCP are using ttyd0 (not cua0 and ttyd0); this should > be a bidirectional port right? A bidirectional port is only bidirectional if incoming opens are incomplete without DCD present and the device prevents DCD from coming present if the outgoing device for the port is already open. > Can somebody please help me out? A terrifically gross "fix" for this is possible: 1) Make the port the controlling tty for mgetty. 2) Make mgetty respect SIGHUP. When it gets SIGHUP, have it close and reopen the line. 3) Modify the tty code. When the outgoing port is openend AND the incoming (mgetty) port is fully open (ie: it is violating the rules like mgetty does and ignoring DCD), send SIGHUP to the process group for the tty. Note that outgoing connections must either not establish the port as their controlling tty, or must do so after this, or the SIGHUP delivery needs to be internal to the tty code (ie: it doesn't really signal the process group, only the part process group on the incoming side). 4) Modify the tty code. When an open is attempted on the incoming device AND the outgoing device is already open, block the open on the incoming device even if it is cheating (like mgetty does) using O_NDELAY. 5) Modify the tty code. When an open is blocked on the incoming device (a result of #4 above), and the last close occurs on the outgoing device, unblock the open on the incoming device. This would probably be the "correct" way to do it, since it would only get tickled if the incoming open refused to wait for DCD like it is most definitely supposed to, according to all that is Holy (mgetty is the spawn of Satan, it only looks like a child process of init). I should not have to twiddle meta-state about a device other than the device information itself (via ioctl()). Lock files are evil, and are the work of AT&T SVR3.x. Multiple processes wanting to go out simultaneously need to be mediated by the exclusive use bit, with special dispensation to exclusive use on tty's being given in the fork() code that duplictes the descriptor table. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501030034.AA02451>