Date: Mon, 3 Feb 1997 13:25:04 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: terry@lambert.org (Terry Lambert) Cc: freebsd-current@freebsd.org Subject: Re: getty patches Message-ID: <19970203132504.RZ25585@usn.blaze.net.au> In-Reply-To: <199702022030.NAA08495@phaeton.artisoft.com>; from Terry Lambert on Feb 2, 1997 13:30:31 -0700 References: <19970202171317.RP40411@usn.blaze.net.au> <199702022030.NAA08495@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > ic=expect send [expect send ...] > > init chat script > > ct#val > > chat timeout in seconds > > Er, what happens if it always fails because the modem is off or has > been taken away entirely? Does it spin forever, or will it eventually > give up? If the init chat fails, it logs via syslog and exits. There is no other sane thing to do. > > 3) A recycle time value, to getty to be periodically > > recycled and initialised after a given number of > > seconds if there is no activity detected. > > What's this for? It is an optional timeout value passed to select(). When select() times out, getty will exit. The end result is that you can have the modems periodically initialised and actually checked to see if they're alive. > > Does anyone have any objecting to me committing these changes? > > I believe they bring our getty more in line with modem technology > > that has been available for over a decade now. :-) > > There are a number of people who have been working on login.conf > changes; at the very least, your /etc/issue capability probably > conflicts with this. No, it doesn't. Since I've been doing most of the login.conf work, I can't see how it would. Login classes can't be activated until after a user logs in, and the issue file is sent before getty prompts for a login name. > I also find it alarming to allow the open to succeed without a > call being present... how do I use the same modem port for > outbound traffic? You don't use this feature. > How do I build a pseduo-device split, so I can have a device for > outbound calls and one for inbound calls, if you always open the > thing for inbound processing? Any way you like, Terry. If you don't wish to use the inbound call features, then don't. That's why it is optional. :-) A blocking open() is still done unless you enable the "ac" capability. 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?19970203132504.RZ25585>