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
-------------------------------------------------------------------------------