Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions
Subject: Re: UUCP Port Turnaround
Message-ID: <13135@sun.uucp>
Date: Thu, 12-Feb-87 05:27:47 EST
Article-I.D.: sun.13135
Posted: Thu Feb 12 05:27:47 1987
Date-Received: Fri, 13-Feb-87 06:27:25 EST
References: <171@ndmath.UUCP> <4090@nsc.nsc.com> <166@piaget.UUCP> <824@sauron.Columbia.NCR.COM>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 49
Keywords: uucp
Xref: watmath comp.sources.wanted:498 comp.unix.wizards:927 comp.unix.questions:1010

>The HDB uugetty will not work on 4.? machines because of the mechanism used
>to check locks.

If this refers to the comment

/*	It will only work on USG systems at least 5.0 or systems	*/
/*	that permit kill(0, pid).					*/

in the "uugetty" source and the comment

 * check to see if the lock file exists and is still active
 * - use kill(pid,0) - (this only works on ATTSV and some hacked
 * BSD systems at this time)

in "ulockf.c", note that 4.[23]BSD *are* systems that permit
"kill(0,pid)" and, as such, support this just fine.  However,
"uugetty" also requires other administrative goo from S5, so it won't
just drop in, and you'd better be able to use it on *all* ports if
you're running vanilla 4.2BSD, since its "init" always runs "getty"
on all ports.

I'm not sure I care for the notion of something that's almost, but
not quite, the same as "getty"; the two programs can easily get out
of sync.  I've seen solutions proposed where you have two "devices"
associated with a terminal port, one for dialing out and one for
other uses.

"getty" opens the "other uses" device and waits for the open to
complete, i.e.  it waits for carrier to come up.

"uucp", etc. open the "dialing out" device, which does *not* wait
for carrier to come up (since most auto-call units these days are
driven by writing stuff to the modem directly before carrier is
established).  If this succeeds, then the modem will (one hopes) give
a busy signal as soon as it's told to pick up the phone and start
dialing, and perhaps will refuse to answer the phone as soon as the
program doing the dialing tells it that it's about to start using it
to dial out.  (The kernel could, conceivably, refuse to acknowledge
carrier coming up if the dialout device is open, but this means the
dialing program couldn't wait for carrier to come up after dialing
without closing the dialout device.)

If "getty" is waiting for the open to complete, and somebody dials
in, causing the open to complete, all opens of the dialout device are
blocked (they return EBUSY or something like that).  This tells
"uucp", etc. to try again later or try another port.  When the dialin
device is closed, dialout opens are again permitted.

This pretty much obviates the need for changes to "getty", etc..