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 Message-ID: <Mutt.19970202153656.j@uriah.heep.sax.de> In-Reply-To: <19970203011153.WC52801@usn.blaze.net.au>; from David Nugent on Feb 3, 1997 01:11:53 %2B1100 References: <19970202171317.RP40411@usn.blaze.net.au> <Mutt.19970202110556.j@uriah.heep.sax.de> <19970203011153.WC52801@usn.blaze.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970202153656.j>