Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!uwvax!husc6!mit-eddie!cybvax0!vcvax1!paul
From: paul@vcvax1.UUCP
Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions
Subject: Re: UUCP Port Turnaround
Message-ID: <218@vcvax1.UUCP>
Date: Sun, 15-Feb-87 23:19:50 EST
Article-I.D.: vcvax1.218
Posted: Sun Feb 15 23:19:50 1987
Date-Received: Mon, 16-Feb-87 19:46:32 EST
References: <171@ndmath.UUCP> <4090@nsc.nsc.com> <166@piaget.UUCP> <13135@sun.uucp> <2386@homxb.UUCP> <13332@sun.uucp>
Organization: VenturCom Inc., Cambridge, MA
Lines: 61
Xref: utgpu comp.sources.wanted:541 comp.unix.wizards:994 comp.unix.questions:1060

> >Venturcom's VENIX did (still does) have hacks like these in the kernel
> >tty driver ....  As far as
> >I'm concerned, hacking the kernel ISN'T the way to go.
> 
> Concluding from one implementation that the concept being implemented
> is wrong is foolish.  Do you have any evidence that the problems with
> VENIX were caused solely by the fact that they modified the kernel?

Since I was involved with the implementation of these features in VENIX,
let me add my eight bits on the subject.

First, I think there are two problems being discussed here: the
switching of terminal lines from dial-in to dial-out (i.e., disabling
getty), and then the actual dialing of the terminal lines.

Regarding the first problem (disabling getty):

The implementation Rick Richardson referred to in VENIX V2
involved modifications to the com drivers, not to the generic tty code itself.
The problems that arose seemed to me to be due to complicated
states occuring when the same tty line was opened simultaneously
by two or more processes, one of which might be blocking on output,
or waiting for carrier, while another might be trying to dial-out and
avoid waiting for carrier.

The generic tty code was not designed to handle these situations
very well, and, after wrestling with the driver code for a while,
we eventually concluded that the problem could be more easily solved at the
user level, particulary since UNIX System V allowed us to easily
disable and enable getty processes through the telinit command.
Perhaps we would have been better of with an implementation
that involved changes to tty.c, as Rick Adams' appeared to do.

Our user-level solution to the problem is through the "ttystate"
command, which uses telinit to control the lines.
Uucp demon scripts must explicity use ttystate to control
the line.  This is certainly clumsier than the kernel-level
solution, which implictly changes the state as needed.
On the other hand, if a problem arises, it is much easier
to straighten things out at the user level that it is at the
kernel level.  My conclusion is: if the kernel solution *really*
works perfectly, I think it's much nicer.  However, if
problems ever arise, I prefer our user-level approach.

Finally, I should add that the problems in VENIX V7 were compounded
by the second of the two problems mentioned above:
the lack of smart-modem dialing software.  We've addressed that in
VENIX System 5 with a separate program which JUST dials modems.
(The program is also called "modem", but I don't think it's the
"modem" that Rick Richardson referred to in his first posting.)
This program doesn't get involved with changing the tty state;
all it does is drive modems.  Uucp communicates with it via
a FIFO, and it emulates an ACU device.  We thus provided
reasonable modem dialing without modifying a line of the UNIX 5.2
uucp code.


Paul Kleppner
VenturCom, Inc.
617/661-1230
{seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul