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