Fix glaring problems.
[rsc] --rw-rw-r-- M 208448 glenda sys 87619 Jan 3 10:38 sys/doc/9.html
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1,9 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1,10
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<title>
-
</title>
<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
- <H1>Plan 9 from Bell Labs
+ <center><H1>Plan 9 from Bell Labs
</H1>
<DL><DD><I>Rob Pike<br>
Dave Presotto<br>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:14,20 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:15,21
Phil Winterbottom<br>
Bell Laboratories, Murray Hill, NJ, 07974
USA<br>
- </I></DL>
+ </center></I></DL>
<H4>Motivation
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:84,90 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:85,91
It soon became clear that this model was richer
than we had foreseen, and the ideas of per-process name spaces
and file-system-like resources were extended throughout
- the system­to processes, graphics, even the network itself.
+ the system—to processes, graphics, even the network itself.
</P>
<P>
By 1989 the system had become solid enough
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:142,148 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:143,149
It also serves as an introduction to the rest of the Plan 9 Programmer's Manual,
which it accompanies. More detail about topics in this paper
can be found elsewhere in the manual.
- </P>
+ </center></P>
<H4>Design
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:167,173 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:168,174
in Plan 9 terminology.
Figure 1 shows the arrangement.
<DL><DT><DD><TT><PRE>
- <br><img src="network.pic.19237420.gif"><br>
+ <br><img src="network.pic.0.gif"><br>
</PRE></TT></DL>
</P>
<DL>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:265,271 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:266,272
(This is a distinction from `object-oriented' models, where these issues
must be faced anew for every class of object.)
Examples in the sections that follow illustrate these ideas in action.
- </P>
+ </center></P>
<H4>The Command-level View
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:272,287 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:273,288
Plan 9 is meant to be used from a machine with a screen running
the window system.
It has no notion of `teletype' in the UNIX sense. The keyboard handling of
- the bare system is rudimentary, but once the window system, 8½ [Pike91],
+ the bare system is rudimentary, but once the window system, 8½ [Pike91],
is running,
text can be edited with `cut and paste' operations from a pop-up menu,
copied between windows, and so on.
- 8½ permits editing text from the past, not just on the current input line.
- The text-editing capabilities of 8½ are strong enough to displace
+ 8½ permits editing text from the past, not just on the current input line.
+ The text-editing capabilities of 8½ are strong enough to displace
special features such as history in the shell,
paging and scrolling,
and mail editors.
- 8½ windows do not support cursor addressing and,
+ 8½ windows do not support cursor addressing and,
except for one terminal emulator to simplify connecting to traditional systems,
there is no cursor-addressing software in Plan 9.
</P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:307,320 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:308,321
<TT>/dev/cons</TT>
(analogous to UNIX's
<TT>/dev/tty</TT>).
- These files are provided by 8½, which is implemented as a file server.
+ These files are provided by 8½, which is implemented as a file server.
Unlike X windows, where a new application typically creates a new window
- to run in, an 8½ graphics application usually runs in the window where it starts.
+ to run in, an 8½ graphics application usually runs in the window where it starts.
It is possible and efficient for an application to create a new window, but
that is not the style of the system.
Again contrasting to X, in which a remote application makes a network
call to the X server to start running,
- a remote 8½ application sees the
+ a remote 8½ application sees the
<TT>mouse</TT>,
<TT>bitblt</TT>,
and
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:366,372 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:367,373
Compatibility was not a requirement for the system.
Where the old commands or notation seemed good enough, we
kept them. When they didn't, we replaced them.
- </P>
+ </center></P>
<H4>The File Server
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:491,497 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:492,498
If we were to upgrade to the new media,
we would have more free space than in the original empty jukebox.
Technology has created storage faster than we can use it.
- </P>
+ </center></P>
<H4>Unusual file servers
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:503,511 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:504,512
There are dozens of such servers; in this section we present three representative ones.
</P>
<P>
- Perhaps the most remarkable file server in Plan 9 is 8½, the window system.
+ Perhaps the most remarkable file server in Plan 9 is 8½, the window system.
It is discussed at length elsewhere [Pike91], but deserves a brief explanation here.
- 8½ provides two interfaces: to the user seated at the terminal, it offers a traditional
+ 8½ provides two interfaces: to the user seated at the terminal, it offers a traditional
style of interaction with multiple windows, each running an application, all controlled
by a mouse and keyboard.
To the client programs, the view is also fairly traditional:
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:526,552 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:527,553
<TT>bitblt</TT>
(RasterOp).
What is unusual is how this is done:
- 8½ is a file server, serving the files in
+ 8½ is a file server, serving the files in
<TT>/dev</TT>
to the clients running in each window.
Although every window looks the same to its client,
each window has a distinct set of files in
<TT>/dev</TT>.
- 8½ multiplexes its clients' access to the resources of the terminal
+ 8½ multiplexes its clients' access to the resources of the terminal
by serving multiple sets of files. Each client is given a private name space
with a
<I>different</I>
set of files that behave the same as in all other windows.
There are many advantages to this structure.
- One is that 8½ serves the same files it needs for its own implementation­it
- multiplexes its own interface­so it may be run, recursively, as a client of itself.
+ One is that 8½ serves the same files it needs for its own implementation—it
+ multiplexes its own interface—so it may be run, recursively, as a client of itself.
Also, consider the implementation of
<TT>/dev/tty</TT>
in UNIX, which requires special code in the kernel to redirect
<TT>open</TT>
calls to the appropriate device.
- Instead, in 8½ the equivalent service falls out
- automatically: 8½ serves
+ Instead, in 8½ the equivalent service falls out
+ automatically: 8½ serves
<TT>/dev/cons</TT>
as its basic function; there is nothing extra to do.
When a program wants to
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:557,563 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:558,564
the files within them make it natural.
</P>
<P>
- 8½ has a unique feature made possible by its design.
+ 8½ has a unique feature made possible by its design.
Because it is implemented as a file server,
it has the power to postpone answering read requests for a particular window.
This behavior is toggled by a reserved key on the keyboard.
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:690,696 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:691,697
to start a window system in a window running a
<TT>cpu</TT>
command; all windows created there automatically start processes on the CPU server.
- </P>
+ </center></P>
<H4>Configurability and administration
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:716,723 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:717,724
by storing private information on local disk.
We reject this style of use,
although the system itself can be used this way.
- In our group, we have a laboratory with many public-access machines­a terminal
- room­and a user may sit down at any one of them and work.
+ In our group, we have a laboratory with many public-access machines—a terminal
+ room—and a user may sit down at any one of them and work.
</P>
<P>
Central file servers centralize not just the files, but also their administration
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:772,778 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:773,779
is instead spent on the newest, fastest multiprocessor servers.
We estimate this costs about half the money of networked workstations
yet provides general access to more powerful machines.
- </P>
+ </center></P>
<H4>C Programming
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:805,811 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:806,812
so all C source files include
<TT><libc.h></TT>.
These rules guarantee that all functions
- are called with arguments having the expected types ­ something
+ are called with arguments having the expected types — something
that was not true with pre-ANSI C programs.
</P>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:909,915 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:910,916
To port network-based software such as X Windows, it was necessary to add
some extensions to those
specifications, such as the BSD networking functions.
- </P>
+ </center></P>
<H4>Portability and Compilation
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1047,1053 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1048,1054
Although simple-minded, this technique works well in practice:
all applications in Plan 9 are built from a single source tree
and it is possible to build the various architectures in parallel without conflict.
- </P>
+ </center></P>
<H4>Parallel programming
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1114,1120 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1115,1121
<TT>rfork</TT>
with the same bits set; programs
use it to create many different forms of sharing and resource allocation.
- A system with just two types of processes­regular processes and threads­could
+ A system with just two types of processes—regular processes and threads—could
not handle this variety.
</P>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1217,1223 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1218,1224
careful operating system support can reduce the difficulty of writing
multi-threaded applications without moving threading and
synchronization primitives into the kernel.
- </P>
+ </center></P>
<H4>Implementation of Name Spaces
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1537,1543 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1538,1544
as an entry in the mount table, they are the same file and the
corresponding substitution from the mount table is made.
This is how the name space is implemented.
- </P>
+ </center></P>
<H4>File Caching
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1559,1571 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1560,1572
This user-level server interposes on the 9P connection to the remote server and
monitors the traffic, copying data to a local disk.
When it sees a read of known data, it answers directly,
- while writes are passed on immediately­the cache is write-through­to keep
+ while writes are passed on immediately—the cache is write-through—to keep
the central copy up to date.
This is transparent to processes on the terminal and requires no change to 9P;
it works well on home machines connected over serial lines.
A similar method can be applied to build a general client cache in unused local
memory, but this has not been done in Plan 9.
- </P>
+ </center></P>
<H4>Networks and Communication Devices
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1686,1692 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1687,1693
The uniform structure for networks in Plan 9 makes the
<TT>import</TT>
command all that is needed to construct gateways.
- </P>
+ </center></P>
<H4>Kernel structure for networks
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1709,1715 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1710,1716
Each module calls the succeeding one to send data up or down the stream.
Like UNIX streams [Rit84],
Plan 9 streams can be dynamically configured.
- </P>
+ </center></P>
<H4>The IL Protocol
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1739,1745 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1740,1746
<P>
In Plan 9, the implementation of IL is smaller and faster than TCP.
IL is our main Internet transport protocol.
- </P>
+ </center></P>
<H4>Overview of authentication
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1804,1815 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1805,1816
Plan 9's authentication structure builds
secure services rather than depending on firewalls.
Whereas firewalls require special code for every service penetrating the wall,
- the Plan 9 approach permits authentication to be done in a single place­9P­for
+ the Plan 9 approach permits authentication to be done in a single place—9P—for
all services.
For example, the
<TT>cpu</TT>
command works securely across the Internet.
- </P>
+ </center></P>
<H4>Authenticating external connections
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1826,1832 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1827,1833
and keys are never sent over the network,
this procedure is not susceptible to replay attacks, yet
is compatible with protocols like Telnet and FTP.
- </P>
+ </center></P>
<H4>Special users
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1880,1886 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1881,1887
by binding them explicitly into the space.
A restricted name space is more secure than the usual technique of exporting
an ad hoc directory tree; the result is a kind of cage around untrusted users.
- </P>
+ </center></P>
<H4>The cpu command and proxied authentication
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1915,1921 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1916,1922
in one domain is the same person as user
<TT>rtmorris</TT>
in another.
- </P>
+ </center></P>
<H4>File Permissions
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1990,1996 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1991,1997
it is read-protected forever.
Drawbacks are that if the file is readable but should have been read-protected,
it is readable forever, and that user names are hard to re-use.
- </P>
+ </center></P>
<H4>Performance
</H4>
<P>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2022,2034 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2023,2035
It also measures the time to send a byte on a pipe from one process
to another and the throughput on a pipe between two processes.
The results appear in Table 1.
- <br><img src="-.19237421.gif"><br>
+ <br><img src="-.1.gif"><br>
Table 1. Performance comparison.
</P>
<br> <br>
Although the Plan 9 times are not spectacular, they show that the kernel is
competitive with commercial systems.
- <H4>Discussion
+ </center><H4>Discussion
</H4>
<P>
Plan 9 has a relatively conventional kernel;
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2173,2179 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2174,2180
to solve our problems.
Through this process, Plan 9 has become a comfortable, productive programming
environment, as well as a vehicle for further systems research.
- </P>
+ </center></P>
<H4>References
<DL COMPACT>
<DT>[9man]<DD>
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2203,2209 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2204,2210
<DT>[ISO10646] <DD>
ISO/IEC DIS 10646-1:1993
Information technology -
- Universal Multiple-Octet Coded Character Set (UCS) ­
+ Universal Multiple-Octet Coded Character Set (UCS) —
Part 1: Architecture and Basic Multilingual Plane.
<DT>[Kill84]<DD>
T.J. Killian,
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2255,2261 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2256,2262
Software - Practice and Experience,
Nov 1987, <B>17</B>(11), pp. 813-845; reprinted in this volume.
<DT>[Pike91]<DD>
- Rob Pike, ``8½, the Plan 9 Window System'',
+ Rob Pike, ``8½, the Plan 9 Window System'',
USENIX Summer Conf. Proc.,
Nashville, June, 1991, pp. 257-265,
reprinted in this volume.
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2279,2285 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2280,2286
Murray Hill, NJ,
1995.
<DT>[POSIX]<DD>
- Information Technology­Portable Operating
+ Information Technology—Portable Operating
System Interface (POSIX) Part 1:
System Application Program Interface (API)
[C Language],
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2333,2339 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2334,2340
<B>63</B>(8), October, 1984.
<DT>[Tric95]<DD>
Howard Trickey,
- ``APE ­ The ANSI/POSIX Environment'',
+ ``APE — The ANSI/POSIX Environment'',
Plan 9 Programmer's Manual,
Volume 2,
AT&T Bell Laboratories,
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:2368,2372 -
/n/sourcesdump/2006/0104/plan9/sys/doc/9.html:2369,2373
</dl>
<br> <br>
<A href=http://www.lucent.com/copyright.html>
- Copyright</A> © 2004 Lucent Technologies Inc. All rights reserved.
+ Copyright</A> © 2006 Lucent Technologies Inc. All rights reserved.
</body></html>
[rsc] --rw-rw-r-- M 208448 glenda sys 87619 Jan 3 10:38 sys/doc/9.html
[rsc] --rw-rw-r-- M 208448 glenda sys 87619 Jan 3 10:38 sys/doc/9.html
|
