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 for terminals w/o modem ctl signals Date: 24 Aug 1993 11:35:33 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 58 Message-ID: <25br95INNg7e@kralizec.zeta.org.au> References: <CBv07B.Hzy@willcox.uucp> <1993Aug16.190323.6894@fcom.cc.utah.edu> <CBvvIG.7vB@obiwan.uucp> <1993Aug17.173025.477@fcom.cc.utah.edu> NNTP-Posting-Host: kralizec.zeta.org.au In <1993Aug17.173025.477@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <CBvvIG.7vB@obiwan.uucp> bob@obiwan.uucp (Bob Willcox) writes: >>... a brain-damaged board that does not have the DTR/DCD signals >>available ... >>As you can see, the DTR/DCD signals never leave the board. As far >>as I can tell, this makes the board useless for modems, but all ... >> >>It sounds (from Bruce's posting) that by setting CLOCAL (and keeping >>it set) sio will work with this setup. Unfortunately, I have not >>had the time to work on this lately. Are you (Bob) sure that the board is brain-damaged enough to require any fixes at all? If the board has xx(x)50 chips, then each port has a DCD input. It would have to be a very braindamaged board to leave the input unconnected. If the board has special chips that emulate an xx(x)50, then the chips need not have DCD inputs, but the xx(x)50 emulation should probably pretend that carrier is always present. >Sorry; I was just using this as an excuse to grouse. The fact that there >were no connections for DTR/DCD at all is exactly analagous to an internal >modem (I know that Control Systems "Hostess" boards support jumpering the >modem control signals on the board, and thought that the BocaBoard was the >same type of animal). Or maybe you are required to set some jumpers to wire DCD on the board itself, as in Terry's example, but have the jumpers set wrong. >This just points out that CLOCAL finagleing is a bad thing(tm), in that >you can not be guaranteed that the settings will "stick" between the open >for the stty and the open for the getty or other program actually using >the port. Agreed :-). Here I think Terry means requiring the clocal setting to live across closes or to have any particular value when ports are opened. >To *make* it work *temporarily*, I would suggest CGD's drivers with the >patches and setting CLOCAL. I don't think cgd's driver is any different from sio here. All of the bidirectional and multiport stuff in sio is supposed to be a direct port from cgd's driver. CLOCAL is handled the same in all 386BSD serial drivers except that sio has different defaults for it (defaults favourable for boards without DCD!). DCD handling was disabled (i.e. broken) in the 0.1 driver so the setting of CLOCAL didn't matter. I think DCD handling is enabled in cgd's driver. It is enabled in sio. Most bugs in DCD handling are inherited from the 0.1 driver. >If you tied CTS to RTS, you could probably >use sio in the same way without much danger of it hanging up. With some sio ignores CTS unless you enable h/w flow control (stty crtscts). Since the CRTSCTS flag is much less standard than the CLOCAL flag and the default setting of off is never inappropriate, there should be no problems with programs turning it on unexpectedly. -- Bruce Evans bde@kralizec.zeta.org.au