kernel/kernel_Notes
1
0
Fork 0
mirror of https://github.com/beyondx/Notes.git synced 2026-02-10 05:46:18 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add New Notes

Browse Source
This commit is contained in:
geekard
2012-08-08 14:26:04 +08:00
commit 5ef7c20052
2374 changed files with 276187 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
Zim/Interview/DMR/Memo.txt Normal file
View File

@@ -0,0 +1,72 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-03T10:46:15+08:00
====== Memo ======
Created 星期五 03 六月 2011
**Proposing a Unix Portability Experiment**
Below is a memo that Steve Johnson and I gave to Elliot Pinson, our boss at the time, proposing the idea of buying a new machine to test the idea of porting Unix to a new architecture. It is, unfortunately, undated. Internal evidence from the document ("around March, 1976") suggests that it must date to ca. the beginning of 1976. The modified-date of the file as I found it is in 1978, but the file was certainly copied or fiddled, because the paper on the outcome of the experiment, "Portability of C Programs and the UNIX System", BSTJ 17 6, July-August 1978, confirms that the proposed machine (an Interdata 8/32) arrived in April 1977.
Johnson's PCC compiler, which would be used for the Interdata project and would later be used for the VAX (Unix 32V) here and at Berkeley (BSD) and then also by important startups like MIPS, SGI, Sun, was evidently in its own late formative stage at the time of writing.
This memo, of course, wasn't a surprise to Pinson. He'd been quite supportive of the idea, and the memo follows a familiar style: researchers want to spend money and time on something, management wants reassurance that the researchers have a moderately coherent idea. Writing this was our equivalent of writing a DARPA or NSF grant proposal, but one that was already a lock.
To explain probably-unfamiliar references: ALTRAN was a language and system for doing symbolic algebra, primarily on polynomials and rational forms; it was mostly the brainchild of W. Stanley Brown. The whole thing was written in hyper-portable Fortran. #3ESS was a not-widely-deployed telephone Central Office for small communities; it used a unique processor (the AP-3). At the time it looked like fun and value for the Bell System for us to move Unix to it, but this didn't pan out.
Unix Portability
S. C. Johnson
D. M. Ritchie
What We Want to Do
We propose a project with three major goals:
1.
to refine and extend the C language to make most C programs portable to a wide variety of machines, mechanically identifying non-portable constructions;
2.
to write a compiler for C which can be changed without grave difficulty to generate code for a variety of machines;
3.
to revise or recode a substantial portion of the Unix system in portable C, detecting and isolating machine dependencies, and demonstrate its portability by moving it to another machine.
From pursuing each goal we hope to attain a corresponding benefit:
1.
improved understanding of the proper design of languages which, like C, operate on a level close to that of real machines but which can be made largely machine-independent;
2.
a C compiler which can be adapted to other machines (independently of Unix), and which puts in practice some recent developments in the theory of code generation;
3.
a working, if perhaps crude and incomplete, implementation of Unix on at least one other machine, with the hope that other implementations will be fairly straightforward.
What We Cannot Do
The common theme here is portability on a bold, apparently unprecedented, scale: we are attempting to make `portable' a multi-access, multi-programming operating system complete with enough utility programs to make it useful as a production tool. It is clear that the degree of portability promised cannot approach that of ALTRAN, for example, which can be brought up with a fortnight of effort by someone skilled in local conditions but ignorant of ALTRAN itself. We do not plan that the C language be bootstrapped by means of a simple interpreter of an intermediate language; instead an acceptably efficient code generator must be written. The compiler will indeed be designed carefully so as to make changes easy, but for each new machine it will inevitably demand considerable skill even to decide on data representations and run-time conventions, let alone code sequences to be produced.
Likewise, although we hope to isolate the machine dependent portions of the operating system into a set of primitive routines, implementation of these primitives will involve deep knowledge of the most recondite aspects of the target machine, including the details of I/O operations and memory protection and relocation.
Next, the sheer bulk of code potentially involved is quite great, on the order of 100,000 lines, counting standard Unix utilities written in C but not subroutines or assembly-language routines and interfaces. Even if many of these utilities are dispensible at first, even if they are mostly portable anyway, even if we are able to discover non-portable constructs mechanically and unerringly, there will still be plenty of work in transporting them.
In view of the intrinsic difficulties of our project, we feel well justified in rejecting a number of sub-goals which might seem otherwise defensible. Thus, we cannot hope to make a portable Unix system compatible with software, file formats, or inadequate character set that may already exist on the machine to which it is moved; to promise to do so would impossibly complicate the project and, in fact, might destroy the usefulness of the result. If Unix is to be installed on a machine, its way of doing business must be accepted as the right way; afterwards, perhaps, other software can be made to work.
Where We Are
Each of the goals we mentioned initially has some characteristic problems associated with it. Since we have devoted careful attention only to the portability of C programs, and have uncovered several difficulties therein, we will discuss that aspect of the project.
Most of the C difficulties stem from the twin assumptions that pointers and integers require the same space in storage, and that pointers to an object of a given type (for example integers) are usable as pointers to a more finely-divided type (for example characters). The first assumption is stated explicitly in the C definition, and happens to be realistic on the only machines for which C has been completely implemented (PDP-11, H6000, S/370). It is used when two structures, which differ by substitution of an integer for a pointer, are assumed to be congruent; when the number `0' is used as an argument to a function expecting a pointer, to indicate a null value; and when a function delivering a pointer remains undeclared (and thus implicitly integer-valued). This assumption fails on some potentially interesting machines, such as the ESS #3 CC (a.k.a AP-3), which has 16-bit integers and 20-bit pointers.
The second assumption, that various sorts of pointers are compatible, is visible most dramatically in the current I/O interfaces to the operating system. The `read' call, for example, is equally happy to receive a character pointer as a destination for bytes as it is an integer pointer through which to store integers. This assumption too fails on many machines, including most word-oriented 16-bit machines as well as the Sigma 5.
If C, like PL/1 and Algol 68, required declarations of functions and of their arguments to be visible at the time of their use, the effects of these assumptions would be largely mitigated because the compiler could insert the appropriate conversions. It remains to be seen whether the burden of inserting such declarations is adequately compensated for. In any event, we have a useful tool (the `lint' program) for discovering inappropriate associations between integers and pointers; it can be modified, if need be, to produce the required declarations automatically.
Work on the portable C compiler is well under way; it uses the YACC-based `front-end' which has existed for some time. Examination of the operating system proper has not begun.
What We Want
We would like to obtain a new machine, and have easy access to it from the Research Unix machine, around March, 1976; by that time the new compiler should be working well. Two factors will govern the choice of this machine. It should not be so similar to the PDP-11 that the exercise becomes trivial, nor should it be so peculiar that the result is unnecessarily complicated or inefficient. Moreover, if the machine is attractive in its own right, then even the initial implementation of portable Unix may find an immediate market in the Bell System and elsewhere.
Copyright © 1998 Lucent Technologies Inc. All rights reserved.

181
Zim/Interview/DMR/Writings_from_the_Past--Dennis_M._Ritchie.txt Normal file
View File

@@ -0,0 +1,181 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-03T09:31:20+08:00
====== Writings from the Past--Dennis M. Ritchie ======
Created 星期五 03 六月 2011
http://cm.bell-labs.com/cm/cs/who/dmr/notes.html
===== Writings from the Past =====
**Machine-readable** versions of early Unix material are hard to come by, even for us. "Backup" in those days (1969 through the early 70s) consisted of punched cards, paper tapes, or uploading to a Honeywell machine. We no longer have those cards, tapes, or the Honeywell.
When we got a **PDP-11** around 1971, we did get **DECtape**, and did save some material, though not enough. A few years ago Keith Bostic and Paul Vixie resurrected a PDP-11 DECtape drive and offered to read any old tapes we might have around, and I sent several to them. These notes are among the small treasures discovered there.
Two files named "**notes1**" and "**notes2**" were on the tape labelled "DMR", and their date, if I correctly interpret the time representation on the tape, is 15 March, 1972.
I reproduce them below. I have no memory of why I wrote them, but they look very much like something to have in front of me for a talk somewhere, because of the references to slides. From the wording at the end ("the public, i.e. other Labs users"), I gather that it intended to be internal to Bell Labs. HTML markup and the corrections and annotations in [] were added in September 1997, but otherwise it's original.
**Dennis**
===== notes1 =====
UNIX is **a general-purpose timesharing operating system** for the Digital Equipment Corp PDP-11.
It is the only such system known to me; in any case it is probably the first. DEC, in particular, shows no signs of producing a** multi-user** system.
==== Some history and credits. ====
UNIX was written by **K. Thompson**. I wrote much of the system software; Ken most of the rest; Other contributors have been Joe Ossanna, Doug McIlroy, and Bob Morris.
The first UNIX was on a** PDP-7**. Most features were present, some in rudimentary form.
UNIX-11 system was largely written in **Jan.-Mar., 1971**; since the[n] changes are generally refinements.
The charter for the project, and the reason the machine was obtained, **was to develop a document editing and formatting system**. The original notion was to **use UNIX as a development tool only, and have the editing system run stand alone**. [This is true as it applies to justifying the purchase of the PDP-11. The earlier work on the PDP-7 just happened in the course of doing research.]
It turned out, however, that it was quite practical to have the editing system run under UNIX, and this is [how it] operates.
The editing system is now being used by the Patent Division at Murray Hill to **prepare patent applications**. I undertand that the bulk of the applications are being done by UNIX. UNIX is also being tried out by two typists in the MH typing pool.
At the start I stated that UNIX was a general-purpose time-sharing system. I imagine the concept is familiar, but I want to bring out a few points.
**First, it is general purpose. **This means it may, or may not, be suitable **as a basis for various special-purpose applications**. The two things that come to mind are **management of large data bases** and applications requiring very **rapid real time response**.
For several reasons, not all defensible, very large files of information are not very well handled by the file system proper. I will return to this point.
In the real-time area, the system has no direct hooks to allow a user-written program to respond very rapidly to an external event. **"very rapidly", here, means in less than about half a second**, which is the approximate time to **swap programs off the disk**. There are thoughts about how to arrange this, but it has not been done.
Notice, however, that the system does in fact make rapid responses to events, in the sense that it is able to pick up characters from typewriter terminals even when they come only a few milliseconds apart. Thus if the "real-time" requirement is really that if **collecting characters **for a terminal or other machine, that ability is already there; what may be lacking is the possibility of **scheduling a non-system program** which wants to act on those characters within a very short time.
So far I have been talking about the disadvantages of the general-purpose system. The advantage lies in the ease with which program development can be done. With any reasonable number of users, responses to user's commands is quite fast, and the cycle of edit-translate-execute-debug is speed-limited by **thinking time, not compute time**. For example, it takes about **50** seconds to assemble and install a new UNIX system.
The time-sharing aspect of the system is also vital to a program development effort, since it means that several people can be using the machine at once.
Likewise when the system is adapted to deal with a particular application, the fact that **multi-programming** is built in from the start means that the most subtle problems which come up when several things must go on at approximately the same time have already been solved.
Given that UNIX is** excellent for program development**, but may have limitations as a base upon which to build a more specialized system, the question arises as to the advisibility of writing one's own system using UNIX. I can only say that of the several projects using UNIX, all have in fact decided to use it not only for development but to support their application directly. Often some modifications to the system have proved necessary, however. Typically these relate, though, to support of some device the standard UNIX does not provide for, and to rearranging the management of core memory.
==== HARDWARE ====
UNIX is running on at least five PDP-11, no two with the same complement of hardware. The slide shows the minimal complement possible.
The basic requirements above a PDP11 processor are
12 K core
some kind of disk
a clock
an EAE (extended arithmetic element, for multiply/divide
Some sort of tape, to provide for loading the system software and saving the disk
Above the minimum, it is of course desirable to have more core, lots of disk, communications interfaces, paper tape reader, and a ROM containing a bootload program.
A summary of the devices which have been attached to actual UNIX systems includes:
DC-11 communications interfaces attached by DATAPHONE to 10, 15, or 30 cps ASCII terminals (not DM-11 as yet)
RF fixed head disk (256K words)
RK moving head disk (1.2M words)
RP moving head disk (2314-style, 10 M words)
paper tape reader/punch
201 DATAPHONE interface
ACU on DATAPHONE
DECtape
Magtape (9-track)
card reader
line printer
==== SOFTWARE ====
There is a good deal of software that goes along with UNIX. It should be pointed out that it was all written using UNIX; none of it comes from DEC or elsewhere.
It should also be pointed out that almost all of it is being worked on in one way or another. That is while all I will list is usable, there are a number of things which we regard as desirable that are not complete.
The major pieces of UNIX software are:
assembler
link editor
text editor
FORTRAN compiler
B compiler
symbolic debugger
text formatting program
M6 macro processor
TMGL compiler-compiler, the last two contributed by Doug McIlroy
command line interpreter
many utilities, mostly to deal in one way or another with the file system
==== SYSTEM ====
The system proper can be regarded as falling into three parts:** the file system, the process control system, and the rest**.
I will only talk about the file system in any detail at all.
Files in UNIX are arranged in **a hierarchical, tree shaped structure.** There are two types of object: **files**, and **directories**. A directory is actually no more than a file, but its contents are controlled by the **system**, and the contents are names of other files. (A directory is sometimes called a catalog in other systems.)
Thus we have the type of arrangement shown in the slide: there is a** root** directory, which is the "base" of the tree (as usual, the tree is upside-down) which contains files and directories.
Each of the directories under the root also can contain files and directories, and so on.
In UNIX, files are named by giving a sequence of directories, separated by slashes, and ending in a file or directory (for example: ...)
The name of the root is "/", and so it begins the sequence.
(example...)
Every user always has a** current directory**, which belongs to him. Files can also be named with respect to the current directory, when the name does not begin with a "/". (examples: ...)
It is possible for the same file to appear in several different directories, under possibly different names. This feature is called "**linking**" (example).
It is also possible for the directory hierarchy to **be split** across several devices. Thus the system can store a directory, and all [files] and directories lower than it in the hierarchy, on a device other than the one on which the root is stored.
In particular, in our own version of the system, there is a directory "**/usr**" which contains **all user's directories**, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk.
notes2
One of the most interesting notions in the file system is the **special file**.
Certain files do not refer to disk files at all, but to** I/O devices**. By conve[n]tion, such special files reside in a **particular directory**, although this is not necessary. When a special file is read or written,** the device it refers to is activated**. For example, all the communications interfaces attached to typewriters have special files associated with them. Thus, provided you have permission, anyone can send a message to another user simply by **writing information onto his typewriter's special file**. There are special files, for example, to refer to the paper tape reader and punch, to the 201 dataphone, the console typewriter, and whatever other devices may be on the system. An effort is made to **make these special files behave exactly the same way that ordinary disk files** behave. This means that programs generally do not need to know whether they are reading or writing on some device or on a disk file.
The system calls to to I/O are designed to be** very simple** to use as well as efficient. There is no notion corresponding to GEFRC on the Honeywell machines and "access methods" in OS [/360 from IBM] because the direct use of system entries is so straightforward.
Files are **uniformly regarded as consisting of a stream of bytes**; the system makes** no assumptions as to their contents**. Thus the** structure of files** is controlled solely by the **programs **which read and write them. A file of ASCII text, for example, consists simply of a stream of characters **delimited by the new-line characters.** The notion of physical record is fairly well submerged.
For example, the system entry to read a file has only** three arguments**: the file which is being read; the location where the information is to be placed; and the number of bytes desired. Likewise the write call need only specify the file under consideration, th[e] location of the information, and the number of characters to write. The system takes care of** splitting the read or written information into physical blocks as required**.
The I/O calls are also apparently **synchronous**; that is, for example, when something is written, so far as the user is concerned, the writing has already been done. Actually the system itself contains** buffers **which contain the information, so that the physical writing may actually be delayed.
There is not distinction between **"random" and sequential I/O**. The read and write calls are sequential in that, for example, if you read 100 bytes from a file, the next read call will return bytes starting just after the last one read. It is however possible to move the read pointer around (by means of a "seek" call) so as to r**ead the file in any order**.
I should say that that it is not always desirable to ignore the fact of **physical record sizes**. Program which reads **one character** at a time from a file is clearly at a disadvantage compared to one which reads many, if only because of system overhead. Thus__ I/O bound programs are well-advised to read and write in multiples of the physical record size__ (which happens to be uniformly 512 bytes). But it is efficiency, not a logical requirement, which dictates this.
==== PROBLEMS ====
I mentioned earlier that UNIX was not especially suited to applications involving vast quantities of data. The reason is this: files are limited in size to **64K** bytes. The reason for this is not particularly defensible, but it has to do with the fact that the PDP-11 **word size is 16 bits**.
There are a couple of ways around this problem. One of them is simply to split one large logical file into several smaller actual files. This approach works for a while. The limitation here comes from the fact that** directories are searched in a linear fashion**. Thus if the are a vast number of files, it can become quite time-consuming tosearch directories to find the files they contain. We have not noticed this to be a problem, so far, it is only a worry.
Another way around the small file size is to use a disk as a special file. For various reasons, when an entire disk drive is accessed as a special file, the size limitation does not occur. Thus one can set up a program which manages its own data-- in effect is its own, special-purpose file system-- and expect reasonable results.
This again bears on the general versus special purpose system: it probably is more efficient anyway to do your own data management, provided the extra labor is worth the cost.
==== PROCESS CONTROL ====
As I said, the second part of UNIX is that part concerned with process control. __A process in UNIX is simply the execution of a program__. Each user has at least one process working on his behalf: its task is to read his typewriter and interpret what he types as commands to the system to do something. The program associated with this process is called the__ Shell__, and it has many valuable features, including the **redirection of I/O**, so that you can execute programs which ordinarily write, for example, on the typewriter, and arrange that their output go on a file.
I will not go into any details, except to say that either by use of the Shell, or from within a program, it is possible to create an asynchronously running process executing any program designated.
==== SUMMARY ====
If you are interested in using UNIX, there are a number of points about which you should be aware.
First, having to do with the PDP-11 hardware:
the PDP-11, although probably more powerful that most people realize, is not a large machine: a PDP-11 can only accommodate 28K 16-bit words of core.
Moreover, the 11-20 has no hardware protection features: any user can at any time crash the system by executing a program with any of an infinite variety of bugs. This fact is probably most important during program development.
The PDP11/45 essentially solves both of these problems, in a very cost-effective way-- it is hardly more expensive than an 11/20 when the total system cost is considered. It has hardware segmentation and 256K of core can be attached. Since we will be one of the first to get and 11/45, there will definitely be a UNIX on it very soon after it arrives. (however the date is still uncertain.)
Perhaps more important is the fact that **UNIX is essentially a two-man operation at present**. Anyone who contemplates a UNIX installation should have available some **fairly sophisticated programming talent **if any modifications planned, as they almost certainly will be. The amount of time that we can spend working on behalf of, or even advising, new UNIX users is limited. Documentation exists, but never seems to be complete.
There have been rumblings from certain departments about taking over the maintenance of UNIX for the public (i.e., other Labs users) but I cannot promise anything.