Date: Fri, 20 Jun 1997 08:15:07 +0000 (GMT) From: Adam David <adam@veda.is> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: getty modem control Message-ID: <199706200815.IAA15687@veda.is> In-Reply-To: <19970620073506.MK21253@uriah.heep.sax.de> from J Wunsch at "Jun 20, 97 07:35:06 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[Adam] > > 1. Would anyone be terribly upset if I added modem string grabbing support > > to getty? This would be useful for logging caller ID and connect speed. [Jörg] > Yep, i'm very reluctant to such things in the regular getty. The > reason for this reluctance is that you gotta abuse the inbound port. > Normally, the inbound port is supposed to block inside open(2) until > carrier arrives. I understand that your intended changes would break > this (as well as David Nugent's changes broke this, see below). > > If you need mgetty, better use mgetty. There's no use to invent a > second all-singing all-dancing getty, i'd be more happy to keep the > standard getty reasonably small, more targeted towards regular needs > and non-broken modems. It's a pity modems don't allow for retrieving the caller-ID afterwards, instead of spitting it out in realtime. The connect speed can be read back on request, probably even between active sessions. Further to the discussion on the subject of (m)getty back in February, would it work to use DSR as RI for those ports without RI? AT&S1 DSR will become active after answer tone has been detected and inactive after the carrier has been lost, i.e. becomes active after RI and before CD (probably too late to catch caller-ID though?). > > 2. I've been trying to use the modem init stuff on FreeBSD 2.2.2 getty. > > DTR lights up but there is no flicker on TXD. After this attempt I can > > no longer access /dev/ttyd0 or /dev/cua00, 'cu' refuses to open the port > > (no light on DTR) because "Line in use". Trying to let getty open cuaa0 resulted in permissions root.wheel 600 and normal inoperativeness was restored by changing back to uucp.dialer 660 I'm not making any progress with using the modem init string capability. (DTR lights up but there is no flicker on TXD) > That's already one of the problems i've been afraid when i've been > objecting against _any_ modem initialization handling back when David > Nugent added it. Fixing all the related programs to chatting with a > modem will become an endless mess. I really don't think this should > go into a regular getty, or after some time, we'll end up with yet > another mgetty. This is silly, will bloat the regular getty, and is > nothing but a duplication of (Gert Doering's in this case) efforts. How could this be farmed out to a separate process? > Non-broken modems do work with a lightweight getty. Broken modems > (and i figure the entire class of modems that is allowed in Australia > belongs into this class) requires special hacks which should IMHO be > left to special programs. > > > If you don't agree on this, please agree on forking off the old > (pre-David N) getty as ``getty-light'', so i could continue to use > this version then. I refuse to use broken modems anyway, and i don't > need the creeping featurism. (Not meant as a personal offense, but as > a general statement.) The whole point was that the user only gets the features requested via specific gettytab entries. Unless requested, they stay out of the way. -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706200815.IAA15687>