netnews@wnuxb.UUCP (Heiby) (04/27/85)
Unix Technical Digest Sat, 27 Apr 85 Volume 1 : Issue 48
Today's Topics:
echoin
RCS
RCS summary
Screen editors & Unix
----------------------------------------------------------------------
Date: 25 Mar 1985 20:14:50-EST
From: ihnp4!decwrl!Tim.Maroney@CMU-CS-K
Subject: echoin
The throughput problem with interactive editors is mostly the context
switching. The editor asks to read a character, switching to system
context. When the user types a character, there is a switch from system
context to editor context. The editor processes the character a little,
then usually there is a switch back to system context to echo the character,
then back to editor context for some processing of the character. Echoin
would eliminate some of this context switching, so it seems like a
worthwhile idea.
However, the idea would have to be elaborated some to be useful. For
instance, if the user types a ^L, the editor may well not want to echo it
back to the screen. In fact, it usually won't, and the same goes for other
control characters. What you really want is for a known subset of ASCII
characters to be echoed back. So some sort of filter in the kernel would
have to exist, probably a 128-bit (16-byte) bitmap. If this were passed to
each echoin call, the overhead of user-to-kernel copying of the map would
take a big bite out of any savings from echoin, it seems. It also seems
that for most processes the map would change very slowly if at all, so
passing it each time would be a waste. The alternative is to add these 16
bits to the kernel data associated with each terminal. (It could also
theoretically be added in the per-process data structure, but most processes
would never use it.) The logical way to set this is by an ioctl on a file
descriptor associated with the terminal.
There is really no need to make up a new system call. Just use read(2),
after calling the appropriate ioctl to inform the terminal driver you want
this mode of operation, supplying the special character bitmap described
above. The read call would then repeatedly read and echo characters, only
returning to the user context with the data on one of the following
conditions:
(1) The buffer specified in the read is full.
(2) A character flagged as special in the bitmap is typed.
(3) The end of the line is reached. (The driver can detect this because it
keeps track of position on the line for tab expansion.)
I think the savings would be quite substantial. Consecutively-typed text
characters are the norm in editing. A sequence of characters of length n
would create only about 1/n of the context switches it creates now.
There is one major drawback. This strategy can only be assured of working
when you are typing at the end of a line, or in some terminals' insert
modes. The editor can, of course, keep track of what terminal it is on, and
where in the line; but in many cases the automatic echoing would be
inappropriate (for instance, in mid-line on a VT52). I think typing at the
end of lines is, again, the norm, so there could still be substantial
performance improvements.
If I have misunderstood the proposal in some way, please fill me in.
-=-
Tim Maroney, Carnegie-Mellon University, Networking
ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim
CompuServe: 74176,1360 audio: shout "Hey, Tim!"
------------------------------
Date: Sun, 14 Apr 85 11:58:12 pst
From: sdcrdcf!hplabs!hp-pcd!orstcs!hakanson (Marion Hakanson)
Subject: RCS
> Date: 8 Apr 85 14:16:05 GMT
> From: cosell@bbn-labs-b.ARPA (Bernie Cosell)
> Subject: Needed: some advice on how to make RCS work
. . .
> Is there some equivalent 'give me the epoch
> of everything' function you can perform when everything is RCS'ed?
The best approach I know of is to put the $Header$ string in your RCS'ed
files. E.g. a lot of C source programs have something like:
static char *RCSID="$Header$";
at or near the top. The "$Header$" gets expanded at 'co' time to look like:
static char *RCSID="$Header: XXX.c,v 1.1 85/02/12 12:46:05 hakanson Exp $";
There are other keywords you can insert in your source code that will
be expanded at checkout time, as well. "$Log$" will insert (as comments)
the log of change messages you entered for each new revision.
> .... But now:
> is there a way to get a makefile set up so that for .c's and .h's in '.'
> it'll use them, but for the ones it can't find it'll use the copies from the
> master directory?
I usually just create an RCS directory in the directory where all the
sources reside normally -- the RCS commands will look for and store
the ',v' files in that directory automatically, if it exists in the
current directory. Then I check everything in using 'ci -u', which
checks everything back out again. Then, I 'co -l' the file I wish to
work on, do my fiddling, and use the makefile that was already there
normally. When I've tested the modifications and found them satisfactory,
I 'ci -u' the file I've been working on, which will then take care of
freezing the changes (and documenting them in the log, as well).
If you don't like having all those files checked in and checked out at
the same time, you can add lines to your makefile something like:
XXX.c: RCS/XXX.c,v
co XXX.c
This tells make how to build XXX.c. I'm not a make wizard, but there is
probably some way you could do the above by adding a default rule which
would tell make how to build .c files from .c,v files, but that's pretty
obscure to me right now. Nevertheless, make will use the XXX.c file
if it is newer than the RCS/XXX.c,v file, which is what you want if you
are modifying it.
Note that there are many other ways of using RCS. My current approach
has been to try to integrate RCS into existing file-system structure,
makefiles, etc., as transparently as possible.
Marion Hakanson CSnet: hakanson@oregon-state
UUCP : {hp-pcd,tektronix,tekchips}!orstcs!hakanson
------------------------------
Date: Tue, 16 Apr 85 11:34:54 EST
From: Bernie Cosell <ihnp4!ucbvax!cosell@bbn-labs-b.ARPA>
Subject: RCS summary
Here's a brief summary of what I've learned:
first off, mostly no one has much worried about listings. It is easy enough to
have 'make' oversee pouring out new listings when you need them, but no one
really worried much about this. Since we are source-licensed, I'm planning to
dive into 'pr' and modify it to take a new option that will have it put the RCS
revision number instead of the last-modified date in the page headers.
Now for getting make to work: well, there are two answers here, depending on
structure of the project. If you are working on something where you can
conveniently 'lock' ALL of the program sources, even though you only co'ed
maybe one or two files, then life is easy: there were several folks who
suggested ways to put the appropriate building rules into make to do the right
thing on-the-fly with .c,v files. Mostly, RCS pretty much works fine for small
programs (or at least programs without too many source files), so for the most
part you can live with the image that if you've checked out one of the source
files you might as well at least 'reserve' them all.
There are problems with really large systems. Some projects just continued the
small-system model and have a single file way at the top of the RCS hierarchy
called "master.lock" or something like that and you always co-l THAT file
before you really try to touch anything. That won't work at all for our
project: much like a UNIX kernel we'll need to have the 'current' system pretty
much available to everyone even while several folk are busily working in
parallel on diverse parts of the system. This is a trickier affair and there
are two practical approaches that could be made to work in this case:
1) If your program modules work out right, you can 'co' things a 'module' at
a time. What you do is make a LIBRARY file (ranlib and all) of all of the
'master' .o files off in the master directory. You cobble up a makefile that
basically builds modules as you would have guessed, but does the final linking
as: cc <your>.o -l<masterlib>
thus, any .o files that you DIDN'T mess with will quietly be snarfed out of the
master copy and you're home free. This should work pretty well, but the
respondents weren't clear how they made make understand the .o dependencies
correctly. That is, you usually have:
SYSTEM: <lots of .o dependencies>
cc <to assemble everything>
but that wont work when the .o files are all hidden. I think what you do in
this case is have a funny makefile entry for each module. NOrmally a module
has a single entry like:
module.o: lots of .c and .h files
now what you do is add
module: module.o
cc module.o -l<masterlib> -o module (or even -o SYSTEM works)
2) Use a hacked-up version of make. The folks at Purdue who brought you RCS
in the first place have also produced a version of make that is better tuned to
working with RCS. It was distributed on the USENIX '84 tape, but we don't have
that and I haven't succeeded in locating a copy of it yet, so I don't know
exactly how it works, but I do have the gist of it:
There is a new environment variable which, since I don't know its real name
I'll call MAKE-PATH. What the new version of make does is search out files by
chasing down the MAKE-PATH. For most normal circumstance you'd have a
MAKE-PATH with exactly two entries in it: '.' followed by <masterdir>,
where <masterdir> is a read-only place where a complete set of everything for
the last 'stable' version of the system is kept. So if you want to work on
something, you just mkdir a new, clean place to work, co whatever you need into
it and just "make" - the things you happened to have copied out will be
accepted in place. Things you didn't mess with will be quietly snarfed from
the master dir. This is nicer than the previous because if you, for example,
change a HEADER file, then this approach will quietly and automatically compile
whatever needs recompiling, while in the other scheme you mostly had to do that
work yourself to figure out 'how much' you had to privately recompile so as to
supplant the right .o files in the masterlib.
I'm currently tracking down a copy of the improved make and we'll probably go
with that, since it seems to do exactly what we want pretty much automatically.
/Bernie
------------------------------
Date: Wed, 20 Mar 85 10:27:09 gmt
From: Robert Stroud <garfield!mcvax!ukc!cheviot!robert>
Subject: Screen editors & Unix
I read the article in Vol 1 #25 about efficient use of screen editors
under Unix with interest. The "echoin" primitive is similar to mechanisms
developed here to run screen editors efficiently over networks. I passed
the article on to Alan Hunter who asked me to post the following reply.
I hope it is of some interest.
+--------------------------------------------------------------------+
| |
| Efficient Screen Editing |
| |
+--------------------------------------------------------------------+
I was interested to see the comments on efficient use of screen
editors from UNIX (tm). Screen editing is a major activity of users
of any system these days and some provision for this in the operating
system I/O interface is desirable.
I am on the system support staff at the University of Newcastle upon
Tyne (England). We run a joint computing service with the University
of Durham (England) on two mainframes running MTS and several smaller
machines (VAXes and 11/44s) running UNIX.
About 95% of our logins are via a local area network, and this allowed
us to provide efficient screen editing using dumb terminals
(Televideos, Hazeltines, VT100s mostly) by putting some of the screen
editor support in the network terminal concentrators. Basically we
taught the concentrators about the echoing of printing characters and
the four cursor movement keystrokes, so that they were handled
locally, and left the rest up to the host. This simple technique
removes most of the single character interactions from the host
machines, with a consequent increase the number of connections that
can be supported and improved response to the user's keystrokes.
For more details see:
J. A. Hunter and N. F. Hall
"A Network Screen Editor Implementation"
Software - Practice & Experience, Volume 12, 843-856 (1982)
More recently, we have done some work under contract to investigate
the use of screen management software over wide area networks. For
this we used a programmable terminal; we see this as the correct route
forward now that PCs are starting to appear on a lot of office desks.
The work was to design "A Simple Screen Management Protocol", or SSMP
for short. It isn't quite as simple as it was when we started to
design it (!) but we have had a fair degree of success. One of our
test sessions was from a terminal in Newcastle to a host machine at
the University of Alberta (Canada), with remarkably good performance.
This was MTS, not UNIX, so please don't ask for software yet!
SSMP provides a virtual terminal model, which has the advantage that
the host editor software doesn't have to know about the intimate
details of 57 varieties of dumb terminal; that's sorted out by the
terminal emulation software. We solve the single character
interaction problem by not doing much of it. The host is presented
with complete input records for the most part; quite a lot of common
editor functions are defined at the terminal. This technique is just
as valid for a directly connected terminal as for a network
connection; move the frequent interaction stuff out to a programmable
terminal and you eliminate the efficiency problem.
SSMP is a fairly general design. It is applicable to existing
software such as emacs, but we don't have any plans to work on that
package at the moment.
There is a not-quite-published document on SSMP. Ask in late April
this year.
Alan Hunter
Computing Laboratory
University of Newcastle upon Tyne
Newcastle NE1 7RU, England
net: Alan_Hunter%newcastle.mailnet@mit-multics.arpa
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)