Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.misc Subject: Re: Using the sio ports with a Modem Date: 8 Aug 1993 08:52:25 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 80 Message-ID: <241bn9INNemm@kralizec.zeta.org.au> References: <1872@dcsc.dla.mil> <1993Jul30.000604.28487@fcom.cc.utah.edu> <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu> NNTP-Posting-Host: kralizec.zeta.org.au In the old article <1993Aug3.051002.2690@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <23ihduINNpre@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: >>(1) if you use only the dialin ports for dialin: >> keep clocal off always, using something like: >> stty -clocal before starting getty ... >You lose modem control signals from the modem, notably carrier loss >notification, which is necessary to cause slattach to realize it has lost >the connection and it needs to be reestablished (or PPP, for that matter). Er, you have the -clocal flag confused. -clocal turns CLOCAL _off_. It must be turned so you _don't_ lose modem control signals (actually there is only one such signal - SIGHUP). >>(2) if you use only the dialin ports for dialout: >> keep clocal on always, using something like: ... >Same problem as above, plus if CLOCAL is set always, a line drop (like a >power failure at your house but not where the computer is) will leave your >login session active for the next caller. ... There is usually no login session to be active in this case, just a comms program, maybe with a live user who can exit from it. The type of case where it would matter is a comms programs that accepts a callback and then execs getty to take the call. But case (2) doesn't cover using the dialout ports for dialin :-). >>(3) if you use only the dialout ports for dialout but don't use the >> dialin ports for dialin: >> same as (2) works but is not necessary for initial dialout; ... >Same as (1). No, same as (2). >>(4) if you use the dialin ports for dialin and the dialout ports for >> dialout: >> same as (1). >Except CLOCAL should never be set on a dialin port (but you aren't exactly >saying it should be set anyway). This is the only really interesting/complicated/broken case. Again I think you have -clocal back to front. The problem here is the opposite. CLOCAL needs to be kept off, but dialout programs might turn it on. If the forget to turn it back off when they exit, then gettys on the dialin port will be adversely affected. >> fd = open(port, O_RDWR | O_NONBLOCK); >> fcntl(fd, F_SETFL, 0); >This shouldn't be necessary (the flags and the non-blocking I/O); it never >has been on Sun, Ultrix, or Sony machines (all BSD boxes). The O_RDWR >should be sufficient. Obviously you are using non-blocking I/O to let you It is necessary, at least if the CLOCAL is off or undefined before the open (the 386BSD getty uses O_RDWR and only works right if CLOCAL is off). >fcntl() the flags on the device do the carrier isn't necessary for blocking >reads (not shown in your code). Again, the partial open hack should be all >that's necessary. You want to coerce the flags pre-open and then set them >after the previous flags have allowed the open to succeed. It has to do The above is simpler than your version of the partial hopen hack - it only opens one fd. However, your version allows the flags (CLOCAL in particular) to be coerced to any required value. Changing them after the open is different for the case where you _don't_ want the open to succeed. Only you version works for that. >... The templating of devices is important for getting >around a program setting O_EXCL on a device file and it being stuck that >way -- such that only one program can ever have it open. Remember that >close on exec is implied for O_EXCL files/devices even if it is never >explicitly set. POSIX doesn't require very much for O_EXCL. I don't know if it excludes this behaviour. -- Bruce Evans bde@kralizec.zeta.org.au