From owner-freebsd-hackers  Fri May 17 10:11:55 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA02652
          for hackers-outgoing; Fri, 17 May 1996 10:11:55 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA02643
          for <hackers@freebsd.org>; Fri, 17 May 1996 10:11:49 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA30725; Sat, 18 May 1996 03:07:24 +1000
Date: Sat, 18 May 1996 03:07:24 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605171707.DAA30725@godzilla.zeta.org.au>
To: hackers@freebsd.org, mtaylor@cybernet.com
Subject: Re: sio setbaud problem
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>When my software sets the baud rate, the DTR is automatically asserted.

>I see that in /sys/i386/isa/sio.c:comparam() that if the divisor is not
>zero, then the DTR gets set ON, otherwise it gets set OFF.

>Is this behavior an "indusrty standard", "POSIX compliance", or whatever?

POSIX says that setting the speed to 0 "... is used to terminate the
connection ... the modem control lines shall no longer be asserted.
Normally this will disconnect the line".  POSIX doesn't specify when the
modem control lines shall be asserted apart than this.  FreeBSD raises
DTR when the speed is nonzero because some programs (e.g. slattach)
expect this.  I don't know if the programs expect this because FreeBSD
does it.  Anyway, it saves them from have to use an ioctl.

>I'm curoius about the reasoning behind this, because I have to use the DTR
>to control a remote device.  This device change change its baud rate to up
>to 115.2 kbps, but the default baud rate is 9600 bps (there's a command sent
>to it to change its baud rate, and setting the DTR causes the device to
>reset).

The POSIX behaviour is only "right" for yesterday's modems :-(.

>(I seem to be having a problem using the RTS as a replacement- the
>status of it does not change, even though I've set CRTS_IFLOW off
>in the c_cflag.  TIOCMGET tells me the RTS is being set, but the
>hardware does not reflect that.)

There is one XXX about this in sio.c.  RTS probably won't stay clear.

Bruce