home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / bsd / 11781 < prev    next >
Encoding:
Text File  |  1993-01-24  |  6.5 KB  |  132 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: uugetty
  5. Message-ID: <1993Jan24.234022.28980@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <1993Jan24.060812.11230@sol.ctr.columbia.edu>
  9. Date: Sun, 24 Jan 93 23:40:22 GMT
  10. Lines: 120
  11.  
  12. In article <1993Jan24.060812.11230@sol.ctr.columbia.edu> umlecla3@ccu.umanitoba.ca (Brian Leclair) writes:
  13. >Hi, has anyone been able to port uugetty over to 386bsd? If so where can i
  14. >ftp it from or where can i get the diffs for it from? I find the usual gettys
  15. >suck... :)
  16.  
  17. There is no need for uugetty under 386BSD, no matter how used to using you
  18. are.  386BSD uses the Berkeley "calling unit" abstraction to turn the line
  19. around, rather than depending on exclusive use and locking files (one
  20. wonders why uugetty does bot, since one should be sufficient).
  21.  
  22. If you are familiar with /dev/ttyXX, /dev/ttyXXm, and /dev/ttyXXM on the
  23. Microport or SunOS systems, then you already know how and why it works.  If
  24. not, then it's fairly simpe to explain.
  25.  
  26.  
  27. WHAT THE uugetty PROGRAM DOES DIFFERENT THAN getty:
  28.  
  29. Basically the difference between uugetty and getty is that uugetty asserts
  30. a lock on the port in either /usr/spool/uucp (for older implementations,
  31. such as the SCO Xenix 2.2.1 version) or /usr/spool/locks (for newer
  32. implementations -- substitute "var" for "usr" if you machine puts its
  33. locks in the "client-server" locations for read-only /usr directories.
  34.  
  35. The uugetty program does not assert the lock until DCD is present and
  36. before spitting out the "login:" banner.  Some uugetty implementations
  37. will either wait for a <CR> before doing this, or optionally wait for a
  38. <CR> if configured to do so.  This is window dressing for people unable
  39. to set up their modems to not assert DCD until real carrier is present
  40. or who have erroneously left CLOCAL set in their gettytab/gettydefs file.
  41.  
  42. In proper operation, uugetty takes advantage of the fact that the open
  43. call to the device to put up the "login:" banner, and, later, fork off
  44. the user's shell as stdin/stdout/stderr, hangs in the kernel until the
  45. modem asserts DCD (we will ignore the badly configured modem instance).
  46.  
  47. Since uugetty is hung in the open, a program like uucico (the transfer
  48. brains of uucp), or cu, or ct, or commercial packages, such as "TERM"
  49. from Century Software (you owe me for the plug, Greg) can assert a lock
  50. on the device prior to dialing.  This way, when the outgoing connection 
  51. causes DCD to be asserted, the lock file will prevent uugetty from
  52. doing I/O until it is removed.
  53.  
  54. Generally, uugetty will "wake up" every so many minute/seconds (this may
  55. also be user configurable in some implementations) to check to see if
  56. the lock is still asserted (and in the case of newer implementations, if
  57. it is still valid -- most time out the lock after 90 minutes even if the
  58. port is still in use!).
  59.  
  60. When uugetty determines that the lock has gone away, it resets to trying
  61. to open the port without DCD.
  62.  
  63. On an incoming call, there is no lock file; therefore when the open
  64. completes, uugetty asserts it's own lock, and spits out the "login:"
  65. banner.  The lock remains asserted throughout the session (although,
  66. again, it may be buggered by the 90 minute time out -- if that happens,
  67. the dial in can be "stepped on" by the outgoing uucp.  The timing out
  68. of lock files is, in my opinion, a stupid feature on machines where the
  69. kill( pid, 0) call can be used to determin if a given pid is running).
  70.  
  71. Because of the "test-for-lock-sleep" loop, it can take up to the uugetty
  72. wake-up time to find out that uugetty sould retry it's open of a device
  73. which was used for an outgoing connection.  This can result in up to 10
  74. minute (or longer!) delays on line "turn around" -- the time between an
  75. outgoing call being terminated and an incoming call being allowed.  This
  76. is because proper set up will not assert DTR to the modem until an open
  77. is waiting on the device, and the modem will not answer the phone without
  78. DTR asserted.  In point of fact, an on-to-off transition of DTR, such as
  79. that which occurs on device close on a correctly set up device will cause
  80. a properly set up modem to reset as if powered off.  This keeps multispeed
  81. modems from locking at one speed.
  82.  
  83.  
  84. Is all this necessary?  (a resounding "No!" echos across the net).
  85.  
  86.  
  87. HOW THE "CALLING UNIT" ABSTRACTION MAGES uugetty OBSOLETE:
  88.  
  89.  
  90. The calling unit abstraction provides two devices; a standard device for
  91. the getty, and a calling unit for outbound traffic.  The kernel prevents
  92. a complete open on both at the same time.
  93.  
  94. The getty opens the /dev/ttyXX device and hangs waiting for DCD.  A
  95. successful open of the /dev/cuXX device prevents the getty open from
  96. completing... thus an outbound call does not need to provide a lock file
  97. for other than contention with other outbound calls.  Since the open in
  98. the getty will not complete until the calling unit device is closed and
  99. DCD is asserted, the getty does not need to be involved in locking.
  100.  
  101. An incoming call on the /dev/ttyXX device asserts DCD, and the getty
  102. open completes.  This locks out all opens on the /dev/cuXX device until
  103. /dev/ttyXX is closed.  Since there is only one inbound server (getty),
  104. this means that no lock files are necessary.  An attempted open of the
  105. /dev/cuXX will return an error code indicating that the device is busy.
  106.  
  107. When the incoming call is terminated, the DCD drop causes the process
  108. to exit (SIGHUP is sent to all processes whose controlling process is
  109. the /dev/ttyXX).  In the case of a normal log out, the last process will
  110. exit before DCD is dropped, and the DTR will drop because of no active
  111. opens on the port.  So if you hang up, it logs you out, and if you log
  112. out, it hangs up.
  113.  
  114. The resoloution of inbound/outbound contention in the kernel greatly
  115. simplifies the process of line turn around, since it means an outbound
  116. line is immediately available for inbound traffic once it is released;
  117. it also means that the getty need not be restarted, and that a special
  118. getty need not be used.
  119.  
  120.  
  121.                     Terry Lambert
  122.                     terry@icarus.weber.edu
  123.                     terry_lambert@novell.com
  124. ---
  125. Any opinions in this posting are my own and not those of my present
  126. or previous employers.
  127. -- 
  128. -------------------------------------------------------------------------------
  129.                                         "I have an 8 user poetic license" - me
  130.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  131. -------------------------------------------------------------------------------
  132.