From owner-freebsd-current Sun Feb 2 06:12:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA19155 for current-outgoing; Sun, 2 Feb 1997 06:12:21 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA19149 for ; Sun, 2 Feb 1997 06:12:12 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id BAA02562; Mon, 3 Feb 1997 01:11:53 +1100 (EST) Message-ID: <19970203011153.WC52801@usn.blaze.net.au> Date: Mon, 3 Feb 1997 01:11:53 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org Subject: Re: getty patches References: <19970202171317.RP40411@usn.blaze.net.au> X-Mailer: Mutt 0.59.1 Mime-Version: 1.0 In-Reply-To: ; from J Wunsch on Feb 2, 1997 11:05:56 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > As David Nugent wrote: > > > I have implemented the following in /usr/libexec/getty: > > Ah, you're going to bloat^H^H^H^H^Hdevelop our getty into another > mgetty? :) No. No fax handling, no unidirectional ports - just standard dialin, no large config file to parse, no "above and beyond the call of duty" featuritis at all, and 1/3 the size in memory and disk requirements of mgetty. > IMO, this approach is a lot less cleaner than the default behaviour > that assumes the modem knows about its DTE speed, and can autoanswer. 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. OTOH, mgetty is certainly bloated from the pov of the functionality I need in 99.999% of cases. > 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. > OTOH, an outgoing call won't be disturbed at all by this scenario > (unlike with the continously listening getty). The open() on the > dialin device will be suspended as soon as the open() on the dialout > device succeeds, so the owner of the dialout device can do what he > wants during this period. Sure, there's still the race that a RING > happens just in this moment, but that's what you gotta live with by > sharing one modem for dialin and dialout anyway. BTW, I'm happy to implement this if someone comes up with the RI detection in open(). An O_RI on open, perhaps? This would be fairly trivial to fold into the patches as they exist now - just an extra line or two in opentty() to add the flag. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/