Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!decwrl!mips!wje From: wje@redwood.mips.com (William J. Earl) Newsgroups: comp.sys.mips Subject: Re: uugetty and /usr/spool/locks Message-ID: <527@spim.mips.COM> Date: 4 Feb 91 19:43:54 GMT References: <9101111107.AA09005@fernwood.mpk.ca.us> Sender: news@mips.COM Reply-To: wje@redwood.mips.com (William J. Earl) Organization: MIPS Computer Systems Inc. Lines: 103 Nntp-Posting-Host: redwood.mips.com In-reply-to: jns@fernwood.mpk.ca.US (Jerry Sweet) Originator: wje@redwood.mips.com In article <9101111107.AA09005@fernwood.mpk.ca.us>, jns@fernwood (Jerry Sweet) writes: > > For me, this note applies to RISC/os 4.51 on an RC3230. > > The man page for uugetty, as well as the Nutshell handbook, leads one > to believe that uugetty will "step aside" for other processes that > wish to use a modem port for which a uugetty process is awaiting login > (presumably via "respawn" in the inittab). This appears not to be the > case. Uugetty, while waiting for login, leaves a lock file in > /usr/spool/locks. > > Kermit, of course, wants to put its lock file in the standard place, > /usr/spool/uucp. If you request the same line for which there is a > uugetty process, you're out of luck---it'll just sit there waiting > for...what? The device to be closed? > > The question is: how does one properly make the alleged "step-aside" > feature of uugetty happen? Does one have to (a) leave the port "off" > in inittab, put up a uugetty only when one is done dialling out on a > port, and then kill the uugetty if one wishes dial out on the same > port again? or (b) kill the uugetty job for that port and quickly try > to grab it before init spawns another uugetty? or (c) do the tedious > thing of having two inittabs, one with uugetty off and one with > uugetty on, etc., etc. ...? uugetty will step aside, but only if it does not yet have "carrier" on the line. If you use an ordinary terminal port (minor device number less than 128), CLOCAL is assumed at open time, at least until some ioctl() changes it. Since uugetty just does open()'s, without and then with O_NDELAY set, to first vhangup() the line and then wait for carrier, uugetty always finds carrier present on an ordinary terminal port. All real RISC/os terminal lines (where "real" means "not pty") have two minor numbers, differing by 128. The device with smaller minor number (such as /dev/tty1, which has major device number 0 and minor device number 1) defaults to CLOCAL on at open time, and the device with the larger minor number (such as /dev/ttym1, which has major device number 0 and minor device number 129) defaults to CLOCAL off. To use uugetty on a modem line, which is to be shared with tip, cu, uucico, and the like, you need to use the device with the larger minor number exclusively, and also set HUPCL and not set CLOCAL in the /etc/gettydefs declaration for the line. For example, to use uugetty on the first line on the first "c8" ("DigiData") serial I/O expansion card on a RC3240, assuming a Hayes-compatible 9600-baud modeem, add to /etc/inittab: m0:234:respawn:/usr/lib/uucp/uugetty -t60 ttymd0 dm_9600 none LDISC0 and add to /etc/gettydefs: dm_9600# B9600 # B9600 SANE TAB3 HUPCL #\r\n\n$HOSTNAME login: #dm_9600 and add to /etc/remote (for use by tip): ttymd0:dv=/dev/ttymd0:br#9600: ttymd1:dv=/dev/ttymd1:br#9600: ttymd2:dv=/dev/ttymd2:br#9600: ttymd3:dv=/dev/ttymd3:br#9600: ttymdialer:dv=/dev/ttymd3,/dev/ttymd2,/dev/ttymd1,/dev/ttymd0:br#9600: ttymd:du:at=hayes:pn=@:tc=ttymdialer: (assuming you have several such lines, /dev/ttymd3, /dev/ttymd2, /dev/ttymd1, and /dev/ttymd0 and want automatic selection of a free line), and add to /usr/lib/uucp/Devices: Direct ttymd0 - 9600 direct Direct ttymd1 - 9600 direct Direct ttymd2 - 9600 direct Direct ttymd3 - 9600 direct ACU ttymd3 - 9600 tb9600 \D ACU ttymd2 - 9600 tb9600 \D ACU ttymd1 - 9600 tb9600 \D ACU ttymd0 - 9600 tb9600 \D In the above, the "Direct" entries are suitable for use with manual dialing via cu and the "ACU" entries are suitable for use for automatic dialing via cu or uucico. Of course, if you only have one line, you can omit the extra names. In any case, the modem must be configured to drop DCD when carrier is lost and to raise DCD only when carrier is detected. The net effect is that when uugetty does an open on a line with CLOCAL not set, the open waits until DCD rises. Meanwhile, if, say, tip opens the line with O_NDELAY set, its open completes immediately. tip will at this point have locked the line. (uugetty briefly locks and then unlocks the line when doing its vhangup(), but leaves it unlocked while waiting in open for DCD.) If tip then dials the phone, and DCD rises, uugetty's open will complete, whereupon uugetty will try to lock the line. uugetty will find the line locked (by tip), so it will then slowly poll for the lock before trying again to wait for carrier. Later, when tip hangs up the phone, and releases its lock, uugetty will acquire the lock and restart the whole process. The above behavior was documented in the RISC/os 4.0 release notes, but this information was unfortunately omitted from the RISC/os 4.50 manual pages. (This is a bug in the latter; I have entered a bug report to that effect, which should be fixed in the near future.) -- William J. Earl wje@mips.com MIPS Computer Systems 408-524-8172 930 Arques Avenue, M/S 1-03 FAX 408-524-8401 Sunnyvale, CA 94086-3650