Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 Fluke 1/4/84; site fluke.UUCP
Path: utzoo!watmath!clyde!floyd!vax135!cornell!uw-beaver!ssc-vax!fluke!joe
From: j...@fluke.UUCP (Joe Kelsey)
Newsgroups: net.unix-wizards,net.bugs
Subject: Terminal output: parity, 7 vs. 8 bits, etc.
Message-ID: <1484@vax4.fluke.UUCP>
Date: Thu, 22-Mar-84 18:01:10 EST
Article-I.D.: vax4.1484
Posted: Thu Mar 22 18:01:10 1984
Date-Received: Sun, 25-Mar-84 07:32:23 EST
Organization: John Fluke Mfg. Co., Everett, WA
Lines: 85
I realize that this may be a new subject of controversy, but it is
probably a subject that should be faced soon. I just received my brand
new VT220 (no flames about the keyboard or packaging please - I believe
that a keyboard is something that grows on you and is also a personal
preference, so let's not discuss that here!) and have been going
through the manual learning about it. Probably the most important
feature of the terminal is that it is the first terminal which supports
true 8-bit ASCII according to the ANSI standard. Now, we all know that
UNIX supports only a 7 bit data path to the terminals (unless you use
RAW or LITOUT mode), so it is not likely to be easy to support the
VT220/240 in 8-bit mode very quickly. However, I think that it is
worth bringing up this topic to see whether or not it would be
worthwhile changing the tty driver to support a general 8 bit data path
in cooked mode.
As I was paging through the tty driver looking at all of the
horrible-ness of the code, I realize that the 7-bit input path is
really a V6 hang-over and will require a monumental effort to expunge.
Probably the tty driver should be completely rewritten, but I don't
want to do it. I did notice one interesting thing - at least in
Berkeley UNIX, you ALWAYS get 7 bit characters with some sort of parity
on output! Unless you choose RAW or LITOUT, both the dz and dh drivers
will set 7bits, even or odd parity on output. Why? Almost every
terminal I have ever set up I alwyas set to ignore parity, and to
generate either no parity or space parity on input (actually output
from the terminal, but sides are confusing here). Is there any real
reason to continue this? I have a proposed change for both the dz and
dh drivers, in the xxparam() function which would only set parity if
the user requested EITHER EVENP OR ODDP, but no if both were set or
neither set. The change is simple, just adding an if statment and else
clause, but I was wondering what effect this would have on terminal
I/O, if any. Here is the change:
*** /sys/vaxuba/dz.c Tue Nov 1 21:24:09 1983
--- dz.c Thu Mar 22 14:37:35 1984
***************
*** 395,400
if (tp->t_flags & (RAW|LITOUT))
lpr |= BITS8;
else
lpr |= (BITS7|PENABLE);
if ((tp->t_flags & EVENP) == 0)
lpr |= OPAR;
--- 395,415 -----
if (tp->t_flags & (RAW|LITOUT))
lpr |= BITS8;
else
+ #ifdef parity_fix
+ /*
+ * Don't actually enable output parity unless the user specifically
+ * request it by setting either EVENP or ODDP (but not both!)
+ * This may help support actual 8-bit output to terminals, but the
+ * issue of 8-bit input is still left dangling. Basically, my
+ * this is to support the VT220 better. jmk 22-mar-84
+ */
+ if ((tp->t_flags&(EVENP|ODDP))==EVENP
+ || (tp->t_flags&(EVENP|ODDP))==ODDP) {
+ #endif parity_fix
lpr |= (BITS7|PENABLE);
+ #ifdef parity_fix
+ } else
+ lpr |= BITS8;
+ #endif parity_fix
if ((tp->t_flags & EVENP) == 0)
lpr |= OPAR;
This is the only place in the entire tty structure that parity is
mentioned. The infamous 'partab' structure is completely useless as a
parity table in Berkeley UNIX. There are EXACTLY three references to
the parity table in the tty driver, all of which use it to select the
character class and discard the parity information. In fact, the
kernel never checks the parity of the character after receiving it from
the device driver. The kernel relies on the device to check and
generate parity. So, why do we need to burden the kernel with any
parity information at all? I personally don't want to figure out how
to make the input path 8 bits in cooked mode, but setting up an eight
bit output path is trivial, if my patch above works.
So, let's hear it. Are there any defenders of a 7 bit input path, or
should someone think about making the terminal I/O 8 bits in each
direction? Is parity useful in anything but noisy line situations? I
would like to hear any and all opinions on this subject. People who
want to flame about the VT2xx can send their comments to /dev/null.
/Joe
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cbosgd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Terminal output: parity, 7 vs. 8 bits, etc.
Message-ID: <1142@cbosgd.UUCP>
Date: Fri, 23-Mar-84 11:02:54 EST
Article-I.D.: cbosgd.1142
Posted: Fri Mar 23 11:02:54 1984
Date-Received: Sun, 25-Mar-84 09:35:47 EST
References: <1484@vax4.fluke.UUCP>
Organization: AT&T Bell Laboratories, Columbus
Lines: 36
With reference to rewriting the tty driver:
The tty driver HAS BEEN rewritten. USG did it in System III. Most
people's initial reaction was "My God, I'm going to have to rewrite
all my software because it's incompatible!" However, in the 3 years
or so since it's been out, people are beginning to appreciate the
orthogonality it presents. You can control most of the hardware bits
(parity, character size, etc) independently. (The one thing you can't
do is have different input and output baud rates, but this feature only
seems to be used at places like Stanford for 1200 baud output with 150
baud input - such modems apparently cost less than real 1200 baud modems.)
Of course, none of the wonderful Berkeley features (crterase, ctlecho,
job control, word erase, line retype, etc) are present in the USG driver,
although the echoe bit is a kludged approximation to crterase.
Of course, this dichotomy of tty drivers (USG vs Berkeley) is the single
most frustrating cause of incompatibility between System V and 4BSD.
My general feeling now is that the ideal tty driver would be the USG tty
driver with the Berkeley extensions added. I think Berkeley feels this
way too. The reason that 4.2BSD does not have a USG-compatible tty driver
in it is that BERKELEY IS NOT LEGALLY ALLOWED TO DO SO. You see, 4.2BSD
is based on UNIX/32V, which costs $300 to universities. System III costs
$3000 to universities, and the improvements from V7 to System III are few
enough and unimportant enough that it just doesn't seem worth it. If
Berkeley includes anything from System III in 4BSD, they must require that
anyone who gets 4BSD buys the more expensive USG license. The System III
manual is apparently not in the public domain, either, like the V7 manual is.
This situation is gradually improving. System V has a more reasonable price
tag on it, and is being aggressively pushed by AT&T as a standard. The
next 4.nBSD will probably require a System V license. So the legal problems
are going away. It might be nice if someone would port the System V tty
driver to 4.2BSD, putting the 4BSD extensions back in, and give it to
Berkeley. (Some upward compatibility code would be crucial as well.)
I can't speak for Berkeley, but I believe they would be interested.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site basser.SUN
Path: utzoo!watmath!clyde!floyd!harpo!decvax!mulga!munnari!basser!boyd
From: b...@basser.SUN (Boyd Roberts)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Terminal output: parity, 7 vs. 8 bits, etc.
Message-ID: <247@basser.SUN>
Date: Sun, 25-Mar-84 19:27:08 EST
Article-I.D.: basser.247
Posted: Sun Mar 25 19:27:08 1984
Date-Received: Wed, 28-Mar-84 01:27:50 EST
References: <1484@vax4.fluke.UUCP>, <1142@cbosgd.UUCP>
Organization: Dept of C.S., University of Sydney
Lines: 31
Dichotomy? You seem to forget about Ritchie's System 3 (now
in system 5) terminal driver. It's beautiful!
Just the thing for controling tty lines. It has selectable
character sizes and parities. The interface to the lower
level hardware tty devices is much cleaner as well (a
pointer to a function called with what action you want done
on the line, block, unblock, start output etc...). And it has
line disciplines too.
Berkeley can keep that revolting (~30k) mess that the call a
terminal driver. I can't recall one of it's "features" being
"wonderful". I shouldn't need to set ~12 options to get my
terminal in a useable state.
Nor do I want that horrible job control stuff. If you want
virtual terminals then use a Blit. What ever happened to
invisibility? Why do *so* many programs have to be modified
to understand about this layer that should have been
invisible to them. But I suppose Berkeley again can justify
that it's ok to break everything in the name of progress.
Another feeble attempt at virtual terminals was the pty(4)
"pseudo terminal driver". How apt.
What happened to "fcntl", why are there ~28 "ioctls"?
Compatibility, come on Mark, Berkeley don't provide it.
Boyd Roberts. ...!decvax!mulga!boyd:basser
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cbosgd.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!ulysses!mhuxl!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Terminal output: parity, 7 vs. 8 bits, etc.
Message-ID: <1169@cbosgd.UUCP>
Date: Wed, 28-Mar-84 23:26:07 EST
Article-I.D.: cbosgd.1169
Posted: Wed Mar 28 23:26:07 1984
Date-Received: Fri, 30-Mar-84 02:29:39 EST
References: <1484@vax4.fluke.UUCP>, <1142@cbosgd.UUCP> <247@basser.SUN>
Organization: AT&T Bell Laboratories, Columbus
Lines: 7
Boyd Roberts sounds like an interesting fellow. Do you know Rob Pike?
If not, someone should introduce you. I bet you two will get along
pretty well. How did you get a Blit in Australia?
Anyway, you're entitled to your own opinion. I think must of us are
pretty happy with the user interface of the 4BSD tty driver, even if
not with the ioctl interface.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wjh12.UUCP
Path: utzoo!linus!vaxine!wjh12!kendall
From: kend...@wjh12.UUCP (Sam Kendall)
Newsgroups: net.unix-wizards,net.bugs
Subject: Berkeley terminal driver user interface
Message-ID: <449@wjh12.UUCP>
Date: Wed, 11-Apr-84 23:10:08 EST
Article-I.D.: wjh12.449
Posted: Wed Apr 11 23:10:08 1984
Date-Received: Thu, 12-Apr-84 05:29:35 EST
References: <249@basser.SUN>
Organization: Delft Consulting Corp., New York
Lines: 21
Several people have condemned the Berkeley terminal driver, saying that
it is large and complicated. A couple have grudgingly admitted their
liking for the terminal interface (but, as Mark Horton says, not for the
ioctl interface).
I think more praise is due the user interface. It is a good thing for a
computer program to be simple outside (specification) and simple inside
(implementation); but a computer is used best when a program is simple
outside but complex inside--the user sees the simplicity, and the
computer takes care of the complexity. In this case the program is the
terminal driver and the outside is the terminal interface. The terminal
interface may be the best possible given intra-line backspacing only,
and very simple from the human point of view; the complexity of the
implementation is no worry of mine.
On the other hand, I refuse to defend the ioctl interface. And I
agree with the more general criticisms of BSD; but I think the terminal
interface of the terminal driver is a notable exception.
Sam Kendall {allegra,ihnp4,ima,amd70}!wjh12!kendall
Delft Consulting Corp. decvax!genrad!wjh12!kendall
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site basser.SUN
Path: utzoo!linus!decvax!mulga!munnari!basser!boyd
From: b...@basser.SUN (Boyd Roberts)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Berkeley terminal driver user interface
Message-ID: <267@basser.SUN>
Date: Fri, 13-Apr-84 13:04:56 EST
Article-I.D.: basser.267
Posted: Fri Apr 13 13:04:56 1984
Date-Received: Sat, 14-Apr-84 08:15:15 EST
References: <249@basser.SUN>, <449@wjh12.UUCP>
Organization: Dept of C.S., University of Sydney
Lines: 20
> I think more praise is due the user interface. It is a
> good thing for a computer program to be simple outside
> (specification) and simple inside (implementation); but
> a computer is used best when a program is simple outside
> but complex inside--the user sees the simplicity, and
> the computer takes care of the complexity.
How can you say that the Berkeley terminal driver (i.e. job control)
provides a simple outside world? Do you not have to fix things
like vi, more and (of all things!!) the shell to understand
about what the terminal driver is likely to do? However only C-shell
was fixed (C-shell too slow).
What do you do when your program dies on a SIGTINT or somebody
you fork hits you with a SIGTTIN or SIGTTOU?
But Berkeley told you it was ok, so there's no worries.
Boyd Roberts ...!decvax!mulga!boyd:basser
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Berkeley terminal driver user interface
Message-ID: <1862@rlgvax.UUCP>
Date: Sun, 15-Apr-84 22:33:52 EST
Article-I.D.: rlgvax.1862
Posted: Sun Apr 15 22:33:52 1984
Date-Received: Tue, 17-Apr-84 08:05:27 EST
References: <249@basser.SUN>, <449@wjh12.UUCP> <267@basser.SUN>
Organization: CCI Office Systems Group, Reston, VA
Lines: 50
We've been over this before, but...
>> I think more praise is due the user interface. It is a
>> good thing for a computer program to be simple outside
>> (specification) and simple inside (implementation); but
>> a computer is used best when a program is simple outside
>> but complex inside--the user sees the simplicity, and
>> the computer takes care of the complexity.
>How can you say that the Berkeley terminal driver (i.e. job control)
>provides a simple outside world? Do you not have to fix things
>like vi, more and (of all things!!) the shell to understand
>about what the terminal driver is likely to do? However only C-shell
>was fixed (C-shell too slow).
The USG driver's interface to character erase is considerably more complicated
than Berkeley's. On a CRT terminal, with Berkeley's, what you see is what
you get 99% of the time, and the other 1% of the time you just hit ^R.
With USG's, what you see is what you get *unless*:
1) what you erased was a TAB
2) what you erased was a control character
and there's *no* ^R facility.
Furthermore, if you hit a control character, you'd better know it's there
because it's echoed as itself - with Berkeley's, it's echoed as ^<whatever>
so at least you know you typed it. This is even more strongly the case for
control characters like ^D which have a special effect on the TTY driver.
Anybody else out there typed a ^D without it being echoed, not been sure whether
it really got there, and typed another one only to find that the first one
*did* get there and the second one logged you out?
>What do you do when your program dies on a SIGTINT or somebody
>you fork hits you with a SIGTTIN or SIGTTOU?
By and large, you don't do anything; the default action for those signals is
to ignore them. If you want or need to use them, you can; otherwise, you
can totally ignore them. If you were thinking about SIGSTOP or SIGTSTP,
again, the default action is what you want in 90% of the cases - when you
get the SIGTSTP, you are immediately put into the stopped state and
automatically restarted when you get a SIGCONT. In the other 10% of the
cases, such as screen editors which have to clear the screen when suspended
and repaint it when restarted, the alternative is something like AT&T's
"job control" which, admittedly, doesn't have stop/start signals so you can
claim you don't have to change your code; you just have to remember to type
^L every time you reactivate "vi"...
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Berkeley terminal driver user interface
Message-ID: <3761@utzoo.UUCP>
Date: Tue, 17-Apr-84 13:58:50 EST
Article-I.D.: utzoo.3761
Posted: Tue Apr 17 13:58:50 1984
Date-Received: Tue, 17-Apr-84 13:58:50 EST
References: <249@basser.SUN>, <449@wjh12.UUCP> <267@basser.SUN>
<1862@rlgvax.UUCP>
Organization: U of Toronto Zoology
Lines: 19
Guy Harris contends, in part:
.............................. the alternative is something like AT&T's
"job control" which, admittedly, doesn't have stop/start signals so you can
claim you don't have to change your code; you just have to remember to type
^L every time you reactivate "vi"...
Wrong! The alternative is a proper window system, which eliminates the
requirement for *either* kludgey special signals *or* explicit repaint
requests. The only thing wrong with AT&T's approach is that they left
it half-finished. Sure, half a window system is better than none, but...
No, Virginia, you do ***NOT*** need a Blit to do windowing right. It
sure does make it easier, and there are a lot of other reasons why you
might want a Blit, but there is no law of nature prohibiting a civilized
window system for ordinary terminals.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry