-
+
/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 systemto processes, graphics, even the network itself. + the system—to processes, graphics, even the network itself.
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. -
+/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.
-
+
/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.
/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:307,320 - /n/sourcesdump/2006/0104/plan9/sys/doc/9.html:308,321 /dev/cons (analogous to UNIX's /dev/tty). - 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 mouse, bitblt, 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. - +/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. -
+/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.
- 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 bitblt (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 /dev 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 /dev. - 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 different 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 implementationit - multiplexes its own interfaceso 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 /dev/tty in UNIX, which requires special code in the kernel to redirect open 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 /dev/cons 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.
- 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 cpu command; all windows created there automatically start processes on the CPU server. -
+/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 machinesa terminal - roomand 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.
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. -
+/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 <libc.h>. 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.
/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. -
+/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. -
+/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1114,1120 - /n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1115,1121 rfork 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 processesregular processes and threadscould + A system with just two types of processes—regular processes and threads—could not handle this variety.
/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. -
+/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. -
+/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 immediatelythe cache is write-throughto 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. -
+/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 import command all that is needed to construct gateways. -
+/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. -
+/n/sourcesdump/2006/0103/plan9/sys/doc/9.html:1739,1745 - /n/sourcesdump/2006/0104/plan9/sys/doc/9.html:1740,1746
In Plan 9, the implementation of IL is smaller and faster than TCP. IL is our main Internet transport protocol. -
+/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 place9Pfor + the Plan 9 approach permits authentication to be done in a single place—9P—for all services. For example, the cpu command works securely across the Internet. -
+/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. -
+/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. -
+/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 rtmorris in another. -
+/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. -
+
/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.
- 
+ 
Table 1. Performance comparison.
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. -
+
