Date: Tue, 4 Feb 1997 19:33:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidn@unique.usn.blaze.net.au (David Nugent) Cc: terry@lambert.org, freebsd-current@freebsd.org Subject: Re: getty patches Message-ID: <199702050233.TAA13904@phaeton.artisoft.com> In-Reply-To: <19970203132504.RZ25585@usn.blaze.net.au> from "David Nugent" at Feb 3, 97 01:25:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> If the init chat fails, it logs via syslog and exits. There is no > other sane thing to do. So is the initd expected to say "getty repeating too quickly on port %s, sleeping" for this? It seems that the current getty isn't expected to fail this way, but the modified getty might. Wouldn't the proper thing for init to do be to disable the port pending a kill -1 1 or something? Waiting an average of 5 minutes for a login when this happens (while initd is busy sleeping it off) seems a bad thing. > > > 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. Right. I guess I was really asking "why does a modem need to be initialized again if it was already initialized? Does initialization (somehow) 'wear off'?". It seems silly to do this, but there might be a perfectly valid reason for it, which I don't see, but which you can now tell me. 8-). > 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 thought different transports could be given different classes in the BSDI implementation. If the BSDI version isn't the design, that's fine (I guess). If the BSDI version can't do it, then it's "generically fine". 8-). > > 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. Uh... yeah, I do. I only have one modem. 8-). > > 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. Ah. I see. So I can use the same modem inbound vs. outbound, as long as I turn this feature off. That's OK, then. Though it would be nice to have inbound calls sorted by type, without keeping me from making outbound calls. I guess we need a method of virtualizing the modem and tracking accesses and/or when it's busy inbound. That's beyond the scope of this set of patches, of course... 8-) Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702050233.TAA13904>