*BSD News Article 20014


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