Date: Tue, 24 Jun 1997 13:47:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: adam@veda.is (Adam David) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG Subject: Re: getty modem control Message-ID: <199706242047.NAA03874@phaeton.artisoft.com> In-Reply-To: <199706232245.WAA26521@veda.is> from "Adam David" at Jun 23, 97 10:45:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > ... on-to-off transition of DTR causes modem reset as > > if powered off then back on ... > > 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. Replace the modem. It is defective. > 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. I don't agree with this. Modems should have a single configuration at power on which works for all uses by the machine they are connected to. The reason you have configurability at all is because you can connect the things to different machines/OS's. > > > Also it is useful to interact with the modem on RING, > > > > ... off-to-on transition of RI ... > > When implemented. When not implemented, the hardware is not useful for interacting with the modem on RING. There's no appologizing for broken hardware. > > 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. So make sure RI is implemented on your serial port, and that the SIO driver can interrupt on it, and that the open call can be given a flag to cause it to hang pending RI instead of DCD. > 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). Well, my point is that if you are going to be hacking out new code to implement a feature, it ought to be good code and not kludge code. > > 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. It's no harder to implement a modem driver than it is to implement a talkative getty, and the modem driver would introduce far fewer technical complications. It seems an easy call to me. If you are worried about send/expect sequences and whether or not the framework is generic, send me your specification for the grammar for a generic interface, and I'll turn it into Yacc and Lex code for you if you can't do it yourself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706242047.NAA03874>