Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Using the sio ports with a Modem Message-ID: <1993Aug9.212558.18441@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu> <241bn9INNemm@kralizec.zeta.org.au> Date: Mon, 9 Aug 93 21:25:58 GMT Lines: 112 In article <241bn9INNemm@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: >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). I already addressed the ordering in terms of context of the quote; I am well aware that the CLOCAL bit means "connection local" and -clocal unsets this bit. >>>(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. Sorry; took "always" to mean "always" rather than referring only to the dialout case. This exeception isn't possible in the case of allowing device templating, something that *must* be done to handle the "smart" multiport drivers that implement part of the tty state handling on the I/O processor instead of the main CPU (in which case templating is required to allow the in-kernel driver to off-load processing to the card by means of a IPC mechanism between the kernel driver and the card. >>>(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. It's not back to front here. The CLOCAL should *never* >*EVER*< be turned on if there is a modem attached! If you prefer, we could call the bit something more suited to its function, like "NOT_A_MODEM", and keep CLOCAL for backward compatability. 8-). Also, device templating it 0 will avoid the problem of someone being silly and setting it 1, since the last close will, by definition, cause a reset to the templated (correct) state. These are the flags valuses in the config file on Sun machines. >>> 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). Only with the current driver, and only because it is broken. It doesn't fall out as "the way things should be". >>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. Actually, AT&T's version, but yes, that's the intent of it. SCO does roughly the same thing in Xenix, even though they are running basically V6 I/O otherwise (rdchk(), et al). >>... 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. I don't think it is possible to make devices "POSIX correct" by nature of the VOP's table being switched out from under the user on open. POSIX is not really into device behaviour one way or the other. What I have described is traditional use of the flag with regard to device drivers with which I'm familiar. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.