From owner-freebsd-current  Sun Feb  2 18:26:14 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id SAA01795
          for current-outgoing; Sun, 2 Feb 1997 18:26:14 -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 SAA01789
          for <freebsd-current@freebsd.org>; Sun, 2 Feb 1997 18:26:09 -0800 (PST)
Received: (from davidn@localhost)
	by labs.usn.blaze.net.au (8.8.5/8.8.5) id NAA14086;
	Mon, 3 Feb 1997 13:25:06 +1100 (EST)
Message-ID: <19970203132504.RZ25585@usn.blaze.net.au>
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
References: <19970202171317.RP40411@usn.blaze.net.au> <199702022030.NAA08495@phaeton.artisoft.com>
X-Mailer: Mutt 0.59.1
Mime-Version: 1.0
In-Reply-To: <199702022030.NAA08495@phaeton.artisoft.com>; from Terry Lambert on Feb 2, 1997 13:30:31 -0700
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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/