Date: Sun, 2 Feb 1997 11:05:56 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org Subject: Re: getty patches Message-ID: <Mutt.19970202110556.j@uriah.heep.sax.de> In-Reply-To: <19970202171317.RP40411@usn.blaze.net.au>; from David Nugent on Feb 2, 1997 17:13:17 %2B1100 References: <19970202171317.RP40411@usn.blaze.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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? :) > 1) Ability to define a modem initialisation script. > 2) Ability to answer incoming phone calls "manually" I don't particularly like these, although unlike mgetty, you make them optional (that's good). I learned to hate the (mis)feature of mgetty to always touch my modem at the wrong time (e.g. after i just hung it up from another program, and wanted to get at it again for redialing). I'm glad i've later on got a modem that doesn't require mgetty anymore. (The best joke mgetty ever gave me was the message that a user named RING has attempted to log in. :-) This basically explains the kind of race conditions you have to expect from such an approach.) IMO, this approach is a lot less cleaner than the default behaviour that assumes the modem knows about its DTE speed, and can autoanswer. Something i've been discussing with the author of mgetty some time ago, and which we agreed to be a Good Thing tm is the implementation of an ``alternate carrier detect''. Right now, the getty has to listen to the port all the time, thus effectively defeating the idea of the split dialin/dialout ports by this (and infact, you gotta run mgetty on the dialout port if you want both directions, or you will fail miserably). Otherwise, it would never get at that RING message. 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''. This would still allow for the kernel semaphore that is implied with the split dialin/dialout devices, but would combine well with the desire to manually answer the call: on the first ring, the open() of the dialin device will (prematurely, compared to the classic scheme) complete, the getty could manually answer the ring, and could also decide which login handler to launch, based on the connect message. The port should continue to follow the normal dialin semantics, i.e. once DCD went high, the falling edge of this signal should SIGHUP the process that has this device as a controlling tty. 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. > 6) Fixed bugs in the %s, %m, %r and %v macros which don't > currently work [uname() was never being called, thus > the values for these were always blank. rlogin seems to > suffer the same bug]. OK. > 7) Sending a sysv-like "issue" file prior the login prompt. OK. -- 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.19970202110556.j>