Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!nsc!jon From: jon@nsc.UUCP (Jon Ryshpan) Newsgroups: net.arch Subject: Re: dumber terminal device drivers Message-ID: <2536@nsc.UUCP> Date: Fri, 29-Mar-85 04:55:17 EST Article-I.D.: nsc.2536 Posted: Fri Mar 29 04:55:17 1985 Date-Received: Sat, 30-Mar-85 01:21:59 EST References: <327@piggy.UUCP> Reply-To: jon@nsc.UUCP (Jon Ryshpan) Distribution: net Organization: National Semiconductor, Sunnyvale Lines: 61 Summary: In article <327@piggy.UUCP> dlm@piggy.UUCP (Daryl Monge) writes: >The individual who first had the idea of removing all the trash from TTY >device drivers wasn't "off the wall". The overhead of user level code >doing much of the work may not be a valid argument. I observe that >the following utilities and applications process character by character >anyway. > EMACS > VI > ksh > vnews > all of our internal graphics applications. > >With the growing list of user friendly applications and utilities, it seems >that fewer and fewer useful programs actually need the device drivers to do >more that read/write characters. (Flow control may be needed there also). Vi runs in raw mode (give or take a brick). Foo! When vi is just accepting text to be input into a file there doesn't seem to be any need for it to wake up every time the user enters a character. It only needs to wake up when something interesting happens - ie. a newline, escape or tab - or if text is being inserted into the middle of a line, and the text to the right needs to be pushed over. What's needed is a general way for vi to tell the terminal handler when it needs to be awakened. Clearly the vi must be wake up whenever its input buffer if full. Also, there are a number of characters that must cause it to wake up. The easiest way to do this is with a system call whose argument is a table with an entry for each character, telling whether it completes the buffer or not. This can be done with a string of 256 bits, or only 8 longwords. There is no reason why this system call should take more time than a single activation of the program, since each involves one trip through the kernel. I think this scheme will handle input to vi when it is accepting text input at the end of a line, so that no nothing needs to be moved over. (This case accouns for a large part of the input to vi, probably most of it.) Whenever vi is ready to accept another line of input, it sets the buffer length to the length of the line to be accepted (the screen width less the wrap margin), and gets text from the terminal. Newline and escape complete the input. If the user enters a tab, vi wakes up, moves the cursor (if necessary) and requests a read for the number of characters remaining on the line. The other control characters are converted to "^". The situation is quite general, and applies to other applications as well: line handlers, communications programs, applications that accept large amounts of text. I have looked at the vi situation in detail because it's sort of complicated, and you might doubt that the scheme would really work here. There is some extra programming to be done to use a facility like this, but there are a lot of cycles to be saved. -> These opinions are my own, and have nothing to do with anything <- -> at National Semiconductor. <- -- Good Luck - Jonathan Ryshpan