Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA7789 ; Tue, 26 Jan 93 07:00:23 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!gatech!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: uugetty Message-ID: <1993Jan24.234022.28980@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <1993Jan24.060812.11230@sol.ctr.columbia.edu> Date: Sun, 24 Jan 93 23:40:22 GMT Lines: 120 In article <1993Jan24.060812.11230@sol.ctr.columbia.edu> umlecla3@ccu.umanitoba.ca (Brian Leclair) writes: >Hi, has anyone been able to port uugetty over to 386bsd? If so where can i >ftp it from or where can i get the diffs for it from? I find the usual gettys >suck... :) There is no need for uugetty under 386BSD, no matter how used to using you are. 386BSD uses the Berkeley "calling unit" abstraction to turn the line around, rather than depending on exclusive use and locking files (one wonders why uugetty does bot, since one should be sufficient). If you are familiar with /dev/ttyXX, /dev/ttyXXm, and /dev/ttyXXM on the Microport or SunOS systems, then you already know how and why it works. If not, then it's fairly simpe to explain. WHAT THE uugetty PROGRAM DOES DIFFERENT THAN getty: Basically the difference between uugetty and getty is that uugetty asserts a lock on the port in either /usr/spool/uucp (for older implementations, such as the SCO Xenix 2.2.1 version) or /usr/spool/locks (for newer implementations -- substitute "var" for "usr" if you machine puts its locks in the "client-server" locations for read-only /usr directories. The uugetty program does not assert the lock until DCD is present and before spitting out the "login:" banner. Some uugetty implementations will either wait for a <CR> before doing this, or optionally wait for a <CR> if configured to do so. This is window dressing for people unable to set up their modems to not assert DCD until real carrier is present or who have erroneously left CLOCAL set in their gettytab/gettydefs file. In proper operation, uugetty takes advantage of the fact that the open call to the device to put up the "login:" banner, and, later, fork off the user's shell as stdin/stdout/stderr, hangs in the kernel until the modem asserts DCD (we will ignore the badly configured modem instance). Since uugetty is hung in the open, a program like uucico (the transfer brains of uucp), or cu, or ct, or commercial packages, such as "TERM" from Century Software (you owe me for the plug, Greg) can assert a lock on the device prior to dialing. This way, when the outgoing connection causes DCD to be asserted, the lock file will prevent uugetty from doing I/O until it is removed. Generally, uugetty will "wake up" every so many minute/seconds (this may also be user configurable in some implementations) to check to see if the lock is still asserted (and in the case of newer implementations, if it is still valid -- most time out the lock after 90 minutes even if the port is still in use!). When uugetty determines that the lock has gone away, it resets to trying to open the port without DCD. On an incoming call, there is no lock file; therefore when the open completes, uugetty asserts it's own lock, and spits out the "login:" banner. The lock remains asserted throughout the session (although, again, it may be buggered by the 90 minute time out -- if that happens, the dial in can be "stepped on" by the outgoing uucp. The timing out of lock files is, in my opinion, a stupid feature on machines where the kill( pid, 0) call can be used to determin if a given pid is running). Because of the "test-for-lock-sleep" loop, it can take up to the uugetty wake-up time to find out that uugetty sould retry it's open of a device which was used for an outgoing connection. This can result in up to 10 minute (or longer!) delays on line "turn around" -- the time between an outgoing call being terminated and an incoming call being allowed. This is because proper set up will not assert DTR to the modem until an open is waiting on the device, and the modem will not answer the phone without DTR asserted. In point of fact, an on-to-off transition of DTR, such as that which occurs on device close on a correctly set up device will cause a properly set up modem to reset as if powered off. This keeps multispeed modems from locking at one speed. Is all this necessary? (a resounding "No!" echos across the net). HOW THE "CALLING UNIT" ABSTRACTION MAGES uugetty OBSOLETE: The calling unit abstraction provides two devices; a standard device for the getty, and a calling unit for outbound traffic. The kernel prevents a complete open on both at the same time. The getty opens the /dev/ttyXX device and hangs waiting for DCD. A successful open of the /dev/cuXX device prevents the getty open from completing... thus an outbound call does not need to provide a lock file for other than contention with other outbound calls. Since the open in the getty will not complete until the calling unit device is closed and DCD is asserted, the getty does not need to be involved in locking. An incoming call on the /dev/ttyXX device asserts DCD, and the getty open completes. This locks out all opens on the /dev/cuXX device until /dev/ttyXX is closed. Since there is only one inbound server (getty), this means that no lock files are necessary. An attempted open of the /dev/cuXX will return an error code indicating that the device is busy. When the incoming call is terminated, the DCD drop causes the process to exit (SIGHUP is sent to all processes whose controlling process is the /dev/ttyXX). In the case of a normal log out, the last process will exit before DCD is dropped, and the DTR will drop because of no active opens on the port. So if you hang up, it logs you out, and if you log out, it hangs up. The resoloution of inbound/outbound contention in the kernel greatly simplifies the process of line turn around, since it means an outbound line is immediately available for inbound traffic once it is released; it also means that the getty need not be restarted, and that a special getty need not be used. Terry Lambert terry@icarus.weber.edu terry_lambert@novell.com --- Any opinions in this posting are my own and not those of my present or previous employers. -- ------------------------------------------------------------------------------- "I have an 8 user poetic license" - me Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial -------------------------------------------------------------------------------