and high-speed networks, and high-performance microprocessors. Thompson and Pike want the OS to be a general-purpose, multiuser, portable distributed system that could be implemented on a variety of computers and networks.
Thus Plan 9 was born. It's less than 600 KB in size and currently has several reference ports, including the Motorola 68020 and above, Sparc, Mips, the Intel 386/486/Pentium family, and Hobbit architectures. Plan 9 is client/server-oriented but with a major difference: Everything is a client, and everything is a server.
Building the Perfect Distributed OS
Plan 9 is
predicated on several principles
. The first is that all objects in the system are e
ither files or file systems. Everything the program can talk to fits into this abstraction. An extension of a goal within the Unix design, Plan 9 takes this idea to its logical end.
In Plan 9, all communication with files is expressed in a protocol that can be transmitted over a wire. Thus everything can be made to be a remote file system. No longer do you have to know where a particular file resides.
Plan 9 also implements some new ideas in how it handles its namespace. The namespace--the set of objects visible to a program--is dynamically and individually adjustable. This is a new idea and has many interesting effects. Essentially it means the set of files the OS can see can be adjusted per process. Therefore, application programs do not need to know where they are running; where, and on what kind of machine, is an economic decision that does not affect the construction of the application itself.
The Plan 9 operating system can run stand-alone or distributed over separate machines actin
g as CPU servers, file servers, and terminals. The pieces are connected by a single file-oriented protocol and local namespace operations. Plan 9 is built from distinct, specialized components rather than from similar general-purpose components.
The Old Distributed Days
Until now, it has been common to connect a group of personal time-sharing systems--workstations--with a medium-speed network. But this has a number of shortcomings. Each workstation has private data, so each must be administered separately; maintenance is difficult to centralize. The machines are replaced every couple years to take advantage of technological improvements, rendering the hardware obsolete, often before it has been paid for.
Most telling, though, is that a workstation is largely a self-contained system, not specialized for any particular task, too slow and I/O-bound for fast compilation and too expensive to be used just to run a window system. To the Plan 9 team, concerned primarily with softwar
e development, it seemed that an approach based on distributed specialization rather than compromise could better address issues of cost-effectiveness, maintenance, performance, reliability, and security. The Bell Labs team decided to build a completely new system and terminal. This gave them an opportunity to rethink and perhaps even replace most of the utilities they had accumulated over the years.
At Your Service
Plan 9 is divided along lines of service function. CPU servers concentrate computing power into large (not overloaded) multiprocessors; file servers provide repositories for storage; and terminals give each user of the system a dedicated computer, with bit-map screen and mouse, on which to run a window system. The sharing of computing and file-storage services provides a sense of community for a group of programmers, amortizes costs, and centralizes and simplifies administration. This architecture is reminiscent of the centralized terminal-to-CPU time-sharing structure
of the '70s. However, Plan 9 has some new and striking differences.
Plan 9 accommodates a variety of different networks. The service pieces communicate by a single protocol, built above a reliable data-transport layer offered by an appropriate network that defines each service as a rooted tree of files. Even for services not usually considered as files, the unified design permits some noteworthy simplification. Each process has a local file namespace that contains attachments to all services the process is using and thereby to the files in those services. One of the most important jobs of a terminal is to support its user's customized view of the entire system as represented by the services visible in the namespace.
Here's how some of the major Plan 9 components work:
CPU servers:
The CPU server performs compilation, text processing, and other applications. It has no local storage; all the permanent files it accesses are provided by remote servers. Transient parts of the nam
espace, such as the collected images of active processes or services provided by user processes, may reside locally, but these disappear when the CPU server is rebooted. Plan 9 CPU servers are as interchangeable for their task--computation--as are ordinary terminals for theirs.
A multiprocessor CPU server has several advantages. The most important is its ability to absorb load. If the machine is not saturated, there is usually a free processor ready to run a new process. This is similar to the notion of free disk blocks in which to store new files on a file system. The comparison extends further: Just as you might buy a new disk when a file system gets full, you can add processors when the system gets busy, without needing to replace or duplicate the entire system. Of course, you can add new CPU servers and share the file servers.
File servers:
Plan 9
file servers hold all
permanent files. The file server presents to its clients a file system rather than a
n array of disks or blocks of files. The files are named by slash-separated components that label branches of a tree and may be addressed for I/O at the byte level. The location of a file in the server is invisible to the client.
An example of how this separation of file services works is how the Plan 9 developers themselves actually use the concept. Their true file system resides on a WORM, an optical disk that can be recorded only once, and is accessed through a two-level cache of magnetic disk and RAM. The contents of the recently used files reside in RAM and are sent to the CPU server rapidly by DMA over a high-speed link, which is much faster than a regular disk although not as fast as local memory. The magnetic disk acts as a cache for the WORM and simultaneously as a backup medium for the RAM. With the high-speed links, it is unnecessary for clients to cache data. Instead, the file server centralizes the caching for all its clients, avoiding the problems of distributed caches.
Namesp
aces:
The protocol for communication with Plan 9 services is file-oriented; all services must implement a file system. That is, each service is arranged into a set of file-like objects collected into a hierarchy called the namespace of the service. When a program calls a Plan 9 service, the program is connected to the root of the namespace of the service. Using the protocol, the program accesses the service by opening, creating, removing, reading, and writing files in the namespace.
From the services available on the network, a Plan 9 user selects those desired: a file server where personal files reside, other servers where data is kept, or a departmental file server where the software for a group project is being written. The namespaces of these various services are collected and joined to the user's own private namespace by a fundamental Plan 9 operator (called
attach
) that joins a service's namespace to a user's. The user's namespace is formed by the union of the spaces of the serv
ices being used. The local namespace is assembled by the local operating system for each user, typically by the terminal. The namespace is modifiable on a per-process level, although in practice much of the namespace is assembled at log-in time and shared by all that user's processes.
One of Plan 9's fundamental operations is attaching network services to the local namespace on a per-process basis. This fine-grained control of the local namespace is used to address issues of customizability, transparency, and heterogeneity.
Applications for Plan 9
An advantage of Plan 9's close relationship with Unix is that many of the applications that run on Unix can be ported to Plan 9. Much of what is delivered as part of the Plan 9 source-code product will be familiar to Unix developers. Not only have Unix applications been ported to Plan 9, but much of the standard command set looks similar to that of Unix.
But does the world need another operating system? It depends on the nic
he being addressed. AT&T sees a niche for Plan 9 in embedded systems and massively parallel systems. Each of these segments has adequate operating systems. However, there is not a consistent standard OS that cohesively connects these systems. Thus Plan 9 may find its place in applications that depend on low-end, single-use devices that must communicate with large-scale application servers.
Plan 9 is available today. Many leading-edge companies are looking to see how they can use it in their businesses and products. Some companies have already found a niche for it. Plan 9 from Bell Labs could be playing soon at a computer near you.
WHERE TO FIND
Plan 9 Resources:
Anonymous FTP:
ftp://plan9.att.com
University of Toronto site:
http://www.ecf.toronto.edu/plan9
Plan 9: Feature Film to Feature-Rich
OS
