From owner-freebsd-current Sun Feb 2 06:53:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA20734 for current-outgoing; Sun, 2 Feb 1997 06:53:46 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA20625 for ; Sun, 2 Feb 1997 06:51:36 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA19677 for freebsd-current@freebsd.org; Sun, 2 Feb 1997 15:51:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id PAA26597; Sun, 2 Feb 1997 15:36:56 +0100 (MET) Message-ID: Date: Sun, 2 Feb 1997 15:36:56 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: getty patches References: <19970202171317.RP40411@usn.blaze.net.au> <19970203011153.WC52801@usn.blaze.net.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970203011153.WC52801@usn.blaze.net.au>; from David Nugent on Feb 3, 1997 01:11:53 +1100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As David Nugent wrote: > > Ah, you're going to bloat^H^H^H^H^Hdevelop our getty into another > > mgetty? :) > > No. No fax handling, ... Well, once you're at the point where you are now, i don't see why it shouldn't be able to do basic fax handling. It's simple: make the lo capability a string of pattern-program pairs, maybe with a default value to fall through: ...:\ :lo=VOICE=/usr/bin/answer;+FCON=/usr/bin/fax;DEFAULT=/usr/bin/login:\ :... > After many years of running a dialin service of some form, > I strongly disagree. Knowing that the modem is alive and > working, answering only if it is "alive" is often critical > to a system's modus operandi. Some basic modem handling > requirements are not all that much 'bloat', imho. I didn't refer to the bloat, but to the uglyness of being required to listen to an incoming port all the time, not just only when there's actually an incoming connection. *This* is what causes all the grief. I'm also running a similiar service (sax.sax.de), and sure, we've got sometimes the case that a machine was hanging and still answering the phones. However, this was an easy case to point out that the hardware was broken (this machine has got serious memory corruption problems, it usually dumps kernel cores twice a week). Still, judging from the races i've seen with mgetty, i always strongly disagreed with the `listen all the time to see my modem's there' approach. > > A better alternate solution is to define an additional port option for > > the dialin port that allows to pick up the port already at the first > > raising edge of the RI signal (ring indicator), by taking this as a > > ``pseudo-carrier''. > > Maybe. I've never found this particularly reliable, whether > due to incorrectly wired cables (RS232, the 'standard' that > everyone implements differently) or buggy serial hardware. For a serious dialin service, you probably won't use this kind of hardware. I don't opt for making the RI pseudo carrier the default (this would violate the POLS), just as an option. > BTW, I'm happy to implement this if someone comes up with the RI > detection in open(). An O_RI on open, perhaps? I rather think it should be an ioctl specific to those drivers that implement it. Sure, it only makes sense if the state of this `enable RI pseudo-carrier' bit is retained across open/close, so you can open the port once with O_NONBLOCK set, issue the ioctl, close the port, and reopen it without the O_NONBLOCK. I'd like to see which opinion Bruce has about this... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)