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 for terminals w/o modem ctl signals Message-ID: <1993Aug17.173025.477@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <CBv07B.Hzy@willcox.uucp> <1993Aug16.190323.6894@fcom.cc.utah.edu> <CBvvIG.7vB@obiwan.uucp> Date: Tue, 17 Aug 93 17:30:25 GMT Lines: 78 In article <CBvvIG.7vB@obiwan.uucp> bob@obiwan.uucp (Bob Willcox) writes: >In article <1993Aug16.190323.6894@fcom.cc.utah.edu>, [ ... flow-control modified nullmodem cable ... ] >>On a 9 pin connecter, not all of RTS, CTS, DTR, and DCD are present. Tie >>the three that are together; this will satisfy the board. >> >>Generally, terminals will not need CTS/RTS or DCD/DSR signals; however, I >>see by your posting you are from IBM. IBM-3101 and similar terminals have >>no way to switch off the requirements for for some signals; pick a line >>that the terminal holds high and use it to hold the needed signals high, >>but don't use the same line for more than 2 or 3 at the same time or you >>may sink too much current. > >Well, these are not IBM-3101s (actually, they happen to be Dell >MT-15s). I don't think I've made myself clear. The adapter that >I'm trying to hook the terminals to is a BocaBoard BB1008. This >is a brain-damaged board that does not have the DTR/DCD signals >available. Connection to the board is via RJ-11 jacks with only >6 conductors. [ ... ] >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 >I'm trying to use it with are locally attached terminals (that are >set up to use software flow-control, they don't support RTS/CTS >flow control). > >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. 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). 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. To *make* it work *temporarily*, I would suggest CGD's drivers with the patches and setting CLOCAL. If you tied CTS to RTS, you could probably use sio in the same way without much danger of it hanging up. With some risk (because signal processing ordering isn't yet correct), you could probably run them through to the terminal -- the risk being in what happens in terms of signal sinking when the terminal is shut off but the machine is not. In point of fact, the calling unit abstraction is still too dirty (or at least not abstracted far enough) to support modem control and non-modem control devices on the same port without sonfiguration. For instance, under SunOS, modem control signals are handled by configuration flags on the device line in the kernel config file. There is an implicit assumption that modem control devices will always be used with calling units. SunOS, a baseline Berkeley derivitive, makes this assumption, and certainly doesn't use CLOCAL in the way that has been suggested, that is as a switch between the use of the ports as modem control or non-modem control devices. With a syntax extension to /etc/gettytab and a modification of getty, this might be a potential soloution; it's probably undesirable, since it would allow a user to kill their own port simply by typing "stty -clocal", and it would only be recoverable with a kill (that would need to be that user or root) and DCD coming high (ie: reboot the machine to get the port back). A suitable fix to sio would be to have the blocking predicated on the open, allowing the kill to cause a cleanup to take place. The main issue to be consizered is that it would no loger be possible to download software, like zmodem or Taylor UUCP off the net and compile it and have it just run with no patches, since a package on the net will always expect SVR4/SVR3/SunOS behaviour, and this would be different enough to be a problem. Good luck on your board; hopefully there will be no kernel hacking required. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.