From owner-freebsd-current Mon Jun 23 15:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA04192 for current-outgoing; Mon, 23 Jun 1997 15:17:33 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA04179 for ; Mon, 23 Jun 1997 15:17:27 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id WAA26521; Mon, 23 Jun 1997 22:45:07 GMT From: Adam David Message-Id: <199706232245.WAA26521@veda.is> Subject: Re: getty modem control In-Reply-To: <199706232056.NAA01663@phaeton.artisoft.com> from Terry Lambert at "Jun 23, 97 01:56:49 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 23 Jun 1997 22:45:06 +0000 (GMT) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Talking to the modem from getty is evil. > > > > Something has to initialise it > > ... set settings ... > AT&W AT&W0 > > (and reassert initialisation). > > ... on-to-off transition of DTR causes modem reset as > if powered off then back on ... AT&D3&W0 Sometimes a modem will hang beyond recovery with DTR toggle, or even with actual power-on reset (less likely). This is why it is useful to initialise on port open, rather than during pre-installation. It is undeniably useful to be able to reconfigure the modem by editing a parameter file, and have the new settings take effect on the next open. > > Also it is useful to interact with the modem on RING, > > ... off-to-on transition of RI ... When implemented. > This is most useful if you want to hang pending an inbound call, > and *then* chat up the modem to direct the call once it is in > progress, but allow outbound connections to occur without process > contention for the port in the absence of an inbound call. Exactly my own premise. > > CONNECT > > ... off-to-on DCD transition ... Yes. > > and hangup events. > > ... on-to-off DCD transition ... Yes. My point is that some _software_ has to respond to these events. Yes, it probably belongs in the modem driver, but we don't have a modem driver (yet). > This is not to say that having a modem *driver* capable of caching > caller ID (and called-ID) for late retrival of the data, and for > multiplexing the modem into "outgoing", "inbound data", "inbound > fax", and "inbound voice" as seperate devices so that each of the > users of the inbound device can hang pending "DCD" instead of > chatting up the modem... would not be useful. Definitely. > Only that your particular arguments for a talkative getty are > invalid. 8-). It's the best we have at this stage. There is no modem driver at the moment. -- Adam David