Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: uugetty for 386bsd Message-ID: <1992Oct20.174948.742@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Reply-To: terry@icarus.weber.edu Organization: Weber State University (Ogden, UT) References: <x-vpr1n_@aix01.rz.fht-mannheim.de> <1992Oct18.191610.1992@draco.bison.mb.ca> Date: Tue, 20 Oct 92 17:49:48 GMT Lines: 165 Well, time to go overboard with another "how it should be" posting. 8-). In article <1992Oct18.191610.1992@draco.bison.mb.ca> root@draco.bison.mb.ca (Dave Rose) writes: >kmw@141.19.1.71 (Karsten M. Winkovics) writes: > >>I am looking for a working uugetty under 386bsd. > >>Anyone got a source? > >>would it be a good idea to recompile Taylor uucp (which seems to be part >>of the etc.01 dist anyway) ? > >I too am interested to see if someone can get uugetty working under >386bsd. If anyone has any suggestions, could you post them to the net? > >As for recompiling uucp, there shouldn't be any need, uucp for 386bsd >works fine out of the box...you just have to do the proper editing of >the /etc/uucp files. The purpose of uugetty is twofold: 1) It waits for a return before spitting anything back; thus an improperly configured modem will continue to operate. I am against this on "moral" grounds; improperly configured modems should fail. The phrase "continue to operate" in this context refers to the ability to answer the phone, and not to their acting correctly in terms of SIGHUP, DTR drop, or baud rate selection via "break"s. 2) It allows bidirectional use of modems. I am against using uugetty for this purpose, since Berkeley has historically provided a cannonical mechanism to do this: calling units. Thus /dev/ttya0 and /dev/cua0 refer to the same device. Additionally, I object to uugetty's creation of UUCP style lockfiles. HDB UUCP and clones do not correctly use the exclusivity mechanism from O_EXCL, which should be sufficient to this task. The existance of these lock files appears to be the result of a misunderstanding of what is called "the partial open hack" in sys2.c in the original SVR3.2 kernel; this is probably because "open order" was not understood with reference to O_EXCL not being reset on an O_NDELAY open -- in actuality, a SVR3.2 UNIX will not reset and of the tty struct contents in the case of O_NDELAY. This was either intentional (unlikely), or the result of misplacing about 12 lines of code in the dup2() system call implementation code, which is also used during a "partial open hack" operation. In any case, Berkeley style calling units obviate the problem. What should be done: 1) Calling unit devices should be created. This can be done by using the highest available bit in the minor device number to represent a modem control device. SCO and Microport both do this, although Microport takes it one step too far by misunderstanding the use of the CLOCAL bit to disable modem control for plain terminal lines (and, potentially, -HUPCL, if fewer wires are used to interface the terminal device). 2) Modifications should be made to the tty handling code: a) The "calling unit" device should not open if the open is complete on the "non calling unit" device which is associated with it (thus, an active login prompt, which requires CLOCAL be set if DCD is not present) or active shell is not interrupted. b) Once the "calling unit" device is opened, the open in progress (assuming a modem, which means CLOCAL would not be set) is blocked until the "calling unit" is closed; in effect, the device is split into two parts, where the bottom part is now usurped by the "calling unit" device (top part) instead of the "non calling unit" device (also top part). c) Signals on the device are reported only to the tty structs associated with the open device -- that is, DCD is not reported to the "non calling unit" device if DCD is raised by the modem on a successful outbound "calling unit" device initiated connection. One of the major problems in the SCO implementation is the confusion of having two devices, both of which may operate simultaneously. Thus the call-out works, but on connection a local host "login:" is echoed down the line to the remote host. This is an error. Login should only be enabled on the "non calling unit" device. d) Flags information should not be shared between versions of the device ("calling unit" vs. "non calling unit"), but mode information should be. Thus baud rate is common, but O_EXCL and O_NDELAY are not. Note that this requires blocking O_NDELAY opens to the device when its counterpart is in use. This is acceptable, as it allows proper fail out on multiple getty's on the same device. Additional suggestions for the tty code: It is probably useful to have "transparent print" devices associated with each device as well ("/dev/tpa0" for "/dev/ttya0"?); in order to do this reliably, we should *not* look at Computone or Intelliport drivers for our models... instead, I suggest Digiboard. The "Computone model" is only aware of the escape sequences to turn the "transparent print" on and off; this information is not even derived from the termcap/terminfo file for the terminal. The result is a hard configuration which can still fail in certain cases. Where does the Computone model fail? Interrupted escape sequences. Since the Computone transparent print device is unaware of the current state of the terminal, it does not know that, in taking over the serial line and outputting a ^S, the transparent print start, print data, the transparent print end, and a ^Q, it is interrupting an escape sequence. Thus it will appear to work most of the time, but will occasionally behave erratically unless the user and the application he is running leave the terminal alone, and all escape sequences are sent atomically within a single write. This requires that we rewrite all applications sending escape sequences to termials to insure that a single escape sequence is not split across multiple write() calls. This we can not do. The alternative is to maintain a state machine for the terminal type in the driver; this is the Digiboard approach. While it limits the number and type of terminals on which transparent print can be supported, it also forces the "transparent print" device to wait until the terminal is in a state where the "print on" sequence will be clearly understood and no ther sequence will be interrupted. Thus, while the available terminal types are reduced, they are supported reliably. A secondary value to maintaining a state machine in the terminal driver is explicit use of the state machine by what I will call "class devices". A "class device" is a device which supports a particular ability of terminals; that is the ability to support multiple pages of memory, such as the various Televideo and Wyse terminals. Thus it is possible to provide multiple terminals on the same serial line by multiplexing multiple "class devices" whose output goes to different pages of memory. I believe this was first done in the drivers of ARNet boards under SCO Xenix 2.2.1. The basic idea is that a user designated key combination will cause the driver (bottom part) to shut off one input source, emit the "page flip" escape sequence, and turn on the alternate input source. The effect is very close to virtual consoles. The trick is to block all driver references for "class devices" which are not currently active. Alternately, one could use the state machine in the driver to maintain a virtual screen representation of the terminal screen contents for each class device. This is much closer to what "screen" does. The advantage here is twofold: first, it now works on terminals where there isn't secondary memory available; second, it doesn't require you block I/O to "inactive" (hidden) class devices. 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 -------------------------------------------------------------------------------