joe@fluke.UUCP (Joe Kelsey) (03/23/84)
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.
/Joemark@cbosgd.UUCP (Mark Horton) (03/23/84)
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.
guy@rlgvax.UUCP (Guy Harris) (03/24/84)
> 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. Exactly. It did require a bit of effort to expunge, but Bell Labs did it in System III. The S3 tty driver (and its successors) was set up to have orthogonal options for controlling the port. For instance, there's a flags word which specifies the baud rate, the character size (5, 6, 7, or 8 bits), the number of stop bits (one or two), whether the receiver is to be enabled or not, the handling of the parity bit, the "hang up on last close" flag, and the "local" flag (ignore carrier - equivalent to LNOHANG bit). By and large, this means these bits get rearranged and dumped directly into the multiplexer's control registers. The stop bits flag is sort of strange; I've always heard that 110 baud was the only baud rate that used two stop bits, but it is consistent with the idea of letting the process control the multiplexer as closely as possible. On the other hand, they decommissioned support of split baud rates, which is a bit INconsistent with letting the process control the multiplexer as closely as possible - admittedly, Bell doesn't like supporting the DH11 but they're still out there. With this scheme, you can have 7 bits plus parity, 8 bits plus no parity, or 8 bits plus parity, for instance. A different flag bit in a different flag word controls 1) whether the character received from the mux is to be stripped down to 7 bits and 2) what is to be done with characters with parity errors. Unfortunately, the 8 bit output path isn't 100% pure. They still stuff things with the 8th bit on into the output clist to indicate delays; if you turn the OPOST bit off, it tells the tty driver to ignore all output transformations (tab expansion, delays, CR/LF stuff, etc.) and you then get a real 8 bit path. At one point I think the people at Berkeley considered picking up the USG driver's "ioctl" interface; I suspect one could build a "old" and "new" tty driver line discipline resembling vanilla and hacked USG UNIX rather than vanilla and hacked V7. I'm thinking of doing that for our 4.2BSD/S3 hybrid system at some point; I didn't like the vanilla V7 driver and don't like the vanilla USG driver much better, and have gotten *very* used to the BSD driver. (We've already convinced the vanilla 4.1c driver to use USG-style "clists".) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
sohail@terak.UUCP (03/24/84)
Firstly I like the vt200 keyboard, we have some freedom 200 terminal that have a similar keyboard and I think that they are great. I would like to hear more about this 8 bit issue, as it is near and dear to my heart. There exist a number of graphics terminal like devices that attach directly to the system bus, and are accessed through the tty drivers. (We at Terak have two such devices.) These kinds of devices certainly do not need to use parity. Sohail.
dmmartindale@watcgl.UUCP (Dave Martindale) (03/24/84)
Two stop bits are usually used with 110 baud because 110 baud's main purpose in life is driving all-mechanical Teletype model 33's. These apparently REQUIRE the extra stop bit to provide enough delay for their mechanical innards to be ready for the start of the next character. For electronic receiving devices, 2 stop bits are never necessary if both receiver and transmitter are operating properly. You might conceivably want to use it in the unlikely event that the transmit or receive clock was sufficiently off-frequency that the transmitter and receiver eventually got out of sync with only 1 stop bit between characters.
gwyn@brl-vgr.ARPA (Doug Gwyn ) (03/25/84)
Before you waste any time hacking on the Berkeley terminal driver, take a look at the one built into all USG UNIXes since at least 1980. It already has full 8-bit capability.
zben@umcp-cs.UUCP (03/25/84)
The terminal I am typing this on (a Volker Craig VC4404) has the bogosity to change bad-parity characters into question marks. Even in cursor addressing sequences. BSD 4.1 is nice enough to generate the parity for me, although I suppose I could do the STTY -EVENP if what you are suggesting comes to pass... Now, you ask, "But why do you have parity set on your terminal at all?". Our local IBM guru has a stick up his *** about having parity checking, and if the switch isn't on I can't talk to his funny IBM Series 1, running Yale code, that makes this terminal look like a 3270. Needless to say raw mode programs lose big this way... Ben Cranston ...seismo!umcp-cs!zben zben@umd2.ARPA
dmmartindale@watcgl.UUCP (Dave Martindale) (03/25/84)
This only serves to point out that terminals as well as computers really should have independent control over whether they generate and whether they check parity.
boyd@basser.SUN (Boyd Roberts) (03/26/84)
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
ron@brl-vgr.ARPA (Ron Natalie <ron>) (03/26/84)
Who needs these extra bits. Parity is for farmers.
hans@log-hb.UUCP (Hans Albertsson) (03/26/84)
[] I do think 8 bits unhindered is worth a try. However; There's a lot of stuff that ought to be fixed up in the tty drivers, notably echoing. ( I'd like a deferred mode as on TOPSXX, that is, Echo when read by requesting program. ) This is not because of the 8 bit standard, which ought never have seen the light of day, but for general data transfer use.
guy@rlgvax.UUCP (Guy Harris) (03/28/84)
> Dichotomy? You seem to forget about Ritchie's System 3 (now > in system 5) terminal driver. It's beautiful! I agree that it's extremely elegant (as does at least one of the major architects of 4.xBSD) - was it also Dennis'? > 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. A lot of it is overkill, but I've gotten used to its handling of control characters (echoing them as ^x, although I wouldn't insist on more than echoing the "special characters" - kill, interrupt, etc. as ^x) and its handling of character erase (again, I wouldn't insist on its handling of line kill, although it's kind of cute). > 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. Blits cost money. Somebody may need features a Blit doesn't have. Job control isn't an attempt at virtual terminals - but then, neither is the S5R2 job control. In order to support virtual terminals without a terminal (such as the Blit or Convergent's PT) designed to support virtual terminals you either have to go through a lot of contortions or you have to have the *program* know that it's dealing with virtual terminals. And the only programs that *need* to know about job control are those that control the full screen (with the S5R2 "virtual terminal" facility, you have to tell the program to repaint its screen when you switch your terminal to it - i.e., you gotta give a ^L to "vi"), those that put the terminal in a non-standard state (i.e., a program which puts a VT100 with a Retro-graphics type graphics board into Tek 4014 emulation mode), or those that want to reprint a prompt when they're restarted (like Mail). "cat", "ls", "ed", and the like don't have to know *anything* about job control - they invisibly get suspended and resumed. "vi" has to get told about it, but the alternative is something like the S5R2 job control, where when you "invisibly" hand control to "vi" (or any other full-screen program) you have to very visibly type a command at it to repaint the screen. > What happened to "fcntl", why are there ~28 "ioctls"? Because "fcntl" is supposed to manipulate file descriptors and "ioctl" is supposed to manipulate devices. I agree that "close on exec" belongs as an "fcntl" function (S3/S5 style) rather than an "ioctl" (V7 style - can't "blame" that one on Berkeley), but the reason the Berkeley TTY driver has so many "ioctl"s is that it's an add-on to the V7 driver which, in turn, was somewhat of an add-on to the V6 driver. As such, you had the original "stty/gtty" layer (3 "ioctl"s - two sets, one which flushes and one which doesn't), the special characters (V7 add-on), the exclusive- use mode (which, I agree, should have been handled as a (file-)descriptor function - and is, in 4.2BSD - rather than an "ioctl" function; 2 "ioctl"s), the "hang up on close" function (one "ioctl" - this was probably done because when they went to V7 they ran out of bits in the "sg_flags" word), and the "flush output" function (one "ioctl"). Then, with the Berkeley system, you add on some more - more than I think were *really* necessary, but if you're adding on more flag bits and control characters you either have to tack them on the side, which V7 already did, or throw out the old "set modes" function and come up with a new one, which Berkeley did. However, there might have been some legal problems with adopting the USG "ioctl"s (BTW, the S3 manual isn't "public domain" as it's Copyright 1980 BTL, but they did make it available to people without source licenses). Count your blessings - at least 4.xBSD (and 2.xBSD) *have* "ioctl"s for the mag tape. We had to hack our own in at Harvard College Observatory - I would much rather have had them a standard part of UNIX at that time. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
tim@ccieng5.UUCP ( Timothy G. Becker) (03/28/84)
My employer isn't about to throw out many thousands of dollars in existing terminals to spend many more thousand on Blits. I'd love to have a Blit. It just isn't going to happen (yet anyway). In the mean time, I love Berkley's job control. It may not be the Blit, but it sure beats the unix environment without it.
mark@cbosgd.UUCP (Mark Horton) (03/29/84)
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.
boyd@basser.SUN (Boyd Roberts) (04/01/84)
Mark Horton says: > 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. That's probably the problem. To many people are satified with dodgy pieces of software. UNIX was a step away from it, but it looks like this is no longer the case. How many "X did Y, now it doesn't" cases have we seen on the net? I know I've seen too many "enhancements" and "features". Options I can do without (cat -v considered harmful). I'll stick to power and clean design. If only there were a few more Rob Pike's...
boyd@basser.SUN (Boyd Roberts) (04/01/84)
> However; There's a lot of stuff that ought to > be fixed up in the tty drivers, notably echoing. > ( I'd like a deferred mode as on TOPSXX, that is, > Echo when read by requesting program. ) That's right, we need delayed echo and deferred writes. The write could be deferred until I'm ready to read it. Then there would be no need for "Terminal Paging in the Kernel".
boyd@basser.SUN (Boyd Roberts) (04/01/84)
> A lot of it is overkill, but I've gotten used to its handling of control > characters. Exactly, it's just overkill.
gwyn@brl-vgr.ARPA (Doug Gwyn ) (04/03/84)
Right on! "cat -v" considered harmful. I think it's funny in a sad sort of way that when USG finally got around to adding Berkeley enhancements, one of the first things they did was to implement "cat -v". Apparently not everyone involved with AT&T UNIX development listens to Rob Pike. Or maybe they do, but are marketing driven so that they are out to supply "features" -- like ""job control"" (even though it is not the same thing as the "job control" that people wanted).