Subversion Repositories planix.SVN

.HTML "Plan 9 from Bell Labs"

.TL

Plan 9 from Bell Labs

.AU

Rob Pike

Dave Presotto

Sean Dorward

Bob Flandrena

Ken Thompson

Howard Trickey

Phil Winterbottom

.AI

.MH

USA

.SH

Motivation

.PP

.FS

Appeared in a slightly different form in

.I

Computing Systems,

.R

Vol 8 #3, Summer 1995, pp. 221-254.

.FE

By the mid 1980's, the trend in computing was

away from large centralized time-shared computers towards

networks of smaller, personal machines,

typically UNIX `workstations'.

People had grown weary of overloaded, bureaucratic timesharing machines

and were eager to move to small, self-maintained systems, even if that

meant a net loss in computing power.

As microcomputers became faster, even that loss was recovered, and

this style of computing remains popular today.

.PP

In the rush to personal workstations, though, some of their weaknesses

were overlooked.

First, the operating system they run, UNIX, is itself an old timesharing system and

has had trouble adapting to ideas

born after it.  Graphics and networking were added to UNIX well into

its lifetime and remain poorly integrated and difficult to administer.

More important, the early focus on having private machines

made it difficult for networks of machines to serve as seamlessly as the old

monolithic timesharing systems.

Timesharing centralized the management

and amortization of costs and resources;

personal computing fractured, democratized, and ultimately amplified

administrative problems.

The choice of

an old timesharing operating system to run those personal machines

made it difficult to bind things together smoothly.

.PP

Plan 9 began in the late 1980's as an attempt to have it both

ways: to build a system that was centrally administered and cost-effective

using cheap modern microcomputers as its computing elements.

The idea was to build a time-sharing system out of workstations, but in a novel way.

Different computers would handle

different tasks: small, cheap machines in people's offices would serve

as terminals providing access to large, central, shared resources such as computing

servers and file servers.  For the central machines, the coming wave of

shared-memory multiprocessors seemed obvious candidates.

The philosophy is much like that of the Cambridge

Distributed System [NeHe82].

The early catch phrase was to build a UNIX out of a lot of little systems,

not a system out of a lot of little UNIXes.

.PP

The problems with UNIX were too deep to fix, but some of its ideas could be

brought along.  The best was its use of the file system to coordinate

naming of and access to resources, even those, such as devices, not traditionally

treated as files.

For Plan 9, we adopted this idea by designing a network-level protocol, called 9P,

to enable machines to access files on remote systems.

Above this, we built a naming

system that lets people and their computing agents build customized views

of the resources in the network.

This is where Plan 9 first began to look different:

a Plan 9 user builds a private computing environment and recreates it wherever

desired, rather than doing all computing on a private machine.

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\(emto processes, graphics, even the network itself.

.PP

By 1989 the system had become solid enough

that some of us began using it as our exclusive computing environment.

This meant bringing along many of the services and applications we had

used on UNIX.  We used this opportunity to revisit many issues, not just

kernel-resident ones, that we felt UNIX addressed badly.

Plan 9 has new compilers,

languages,

libraries,

window systems,

and many new applications.

Many of the old tools were dropped, while those brought along have

been polished or rewritten.

.PP

Why be so all-encompassing?

The distinction between operating system, library, and application

is important to the operating system researcher but uninteresting to the

user.  What matters is clean functionality.

By building a complete new system,

we were able to solve problems where we thought they should be solved.

For example, there is no real `tty driver' in the kernel; that is the job of the window

system.

In the modern world, multi-vendor and multi-architecture computing

are essential, yet the usual compilers and tools assume the program is being

built to run locally; we needed to rethink these issues.

Most important, though, the test of a system is the computing

environment it provides.

Producing a more efficient way to run the old UNIX warhorses

is empty engineering;

we were more interested in whether the new ideas suggested by

the architecture of the underlying system encourage a more effective way of working.

Thus, although Plan 9 provides an emulation environment for

running POSIX commands, it is a backwater of the system.

The vast majority

of system software is developed in the `native' Plan 9 environment.

.PP

There are benefits to having an all-new system.

First, our laboratory has a history of building experimental peripheral boards.

To make it easy to write device drivers,

we want a system that is available in source form

(no longer guaranteed with UNIX, even

in the laboratory in which it was born).

Also, we want to redistribute our work, which means the software

must be locally produced.  For example, we could have used some vendors'

C compilers for our system, but even had we overcome the problems with

cross-compilation, we would have difficulty

redistributing the result.

.PP

This paper serves as an overview of the system.  It discusses the architecture

from the lowest building blocks to the computing environment seen by users.

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.

.SH

Design

.PP

The view of the system is built upon three principles.

First, resources are named and accessed like files in a hierarchical file system.

Second, there is a standard protocol, called 9P, for accessing these

resources.

Third, the disjoint hierarchies provided by different services are

joined together into a single private hierarchical file name space.

The unusual properties of Plan 9 stem from the consistent, aggressive

application of these principles.

.PP

A large Plan 9 installation has a number of computers networked

together, each providing a particular class of service.

Shared multiprocessor servers provide computing cycles;

other large machines offer file storage.

These machines are located in an air-conditioned machine

room and are connected by high-performance networks.

Lower bandwidth networks such as Ethernet or ISDN connect these

servers to office- and home-resident workstations or PCs, called terminals

in Plan 9 terminology.

Figure 1 shows the arrangement.

.KF

.PS < network.pic

.IP

.ps -1

.in .25i

.ll -.25i

.ps -1

.vs -1

.I "Figure 1. Structure of a large Plan 9 installation.

CPU servers and file servers share fast local-area networks,

while terminals use slower wider-area networks such as Ethernet,

Datakit, or telephone lines to connect to them.

Gateway machines, which are just CPU servers connected to multiple

networks, allow machines on one network to see another.

.ps +1

.vs +1

.ll +.25i

.in 0

.ps

.sp

.KE

.PP

The modern style of computing offers each user a dedicated workstation or PC.

Plan 9's approach is different.

The various machines with screens, keyboards, and mice all provide

access to the resources of the network, so they are functionally equivalent,

in the manner of the terminals attached to old timesharing systems.

When someone uses the system, though,

the terminal is temporarily personalized by that user.

Instead of customizing the hardware, Plan 9 offers the ability to customize

one's view of the system provided by the software.

That customization is accomplished by giving local, personal names for the

publicly visible resources in the network.

Plan 9 provides the mechanism to assemble a personal view of the public

space with local names for globally accessible resources.

Since the most important resources of the network are files, the model

of that view is file-oriented.

.PP

The client's local name space provides a way to customize the user's

view of the network.  The services available in the network all export file

hierarchies.

Those important to the user are gathered together into

a custom name space; those of no immediate interest are ignored.

This is a different style of use from the idea of a `uniform global name space'.

In Plan 9, there are known names for services and uniform names for

files exported by those services,

but the view is entirely local.  As an analogy, consider the difference

between the phrase `my house' and the precise address of the speaker's

home.  The latter may be used by anyone but the former is easier to say and

makes sense when spoken.

It also changes meaning depending on who says it,

yet that does not cause confusion.

Similarly, in Plan 9 the name

.CW /dev/cons

always refers to the user's terminal and

.CW /bin/date

the correct version of the date

command to run,

but which files those names represent depends on circumstances such as the

architecture of the machine executing

.CW date .

Plan 9, then, has local name spaces that obey globally understood

conventions;

it is the conventions that guarantee sane behavior in the presence

of local names.

.PP

The 9P protocol is structured as a set of transactions that

send a request from a client to a (local or remote) server and return the result.

9P controls file systems, not just files:

it includes procedures to resolve file names and traverse the name

hierarchy of the file system provided by the server.

On the other hand,

the client's name space is held by the client system alone, not on or with the server,

a distinction from systems such as Sprite [OCDNW88].

Also, file access is at the level of bytes, not blocks, which distinguishes

9P from protocols like NFS and RFS.

A paper by Welch compares Sprite, NFS, and Plan 9's network file system structures [Welc94].

.PP

This approach was designed with traditional files in mind,

but can be extended

to many other resources.

Plan 9 services that export file hierarchies include I/O devices,

backup services,

the window system,

network interfaces,

and many others.

One example is the process file system,

.CW /proc ,

which provides a clean way

to examine and control running processes.

Precursor systems had a similar idea [Kill84], but Plan 9 pushes the

file metaphor much further [PPTTW93].

The file system model is well-understood, both by system builders and general users,

so services that present file-like interfaces are easy to build, easy to understand,

and easy to use.

Files come with agreed-upon rules for

protection,

naming,

and access both local and remote,

so services built this way are ready-made for a distributed system.

(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.

.SH

The Command-level View

.PP

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],

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

special features such as history in the shell,

paging and scrolling,

and mail editors.

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.

.PP

Each window is created in a separate name space.

Adjustments made to the name space in a window do not affect other windows

or programs, making it safe to experiment with local modifications to the name

space, for example

to substitute files from the dump file system when debugging.

Once the debugging is done, the window can be deleted and all trace of the

experimental apparatus is gone.

Similar arguments apply to the private space each window has for environment

variables, notes (analogous to UNIX signals), etc.

.PP

Each window is created running an application, such as the shell, with

standard input and output connected to the editable text of the window.

Each window also has a private bitmap and multiplexed access to the

keyboard, mouse, and other graphical resources through files like

.CW /dev/mouse ,

.CW /dev/bitblt ,

and

.CW /dev/cons

(analogous to UNIX's

.CW /dev/tty ).

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.

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

.CW mouse ,

.CW bitblt ,

and

.CW cons

files for the window as usual in

.CW /dev ;

it does not know whether the files are local.

It just reads and writes them to control the window;

the network connection is already there and multiplexed.

.PP

The intended style of use is to run interactive applications such as the window

system and text editor on the terminal and to run computation- or file-intensive

applications on remote servers.

Different windows may be running programs on different machines over

different networks, but by making the name space equivalent in all windows,

this is transparent: the same commands and resources are available, with the same names,

wherever the computation is performed.

.PP

The command set of Plan 9 is similar to that of UNIX.

The commands fall into several broad classes.  Some are new programs for

old jobs: programs like

.CW ls ,

.CW cat ,

and

.CW who

have familiar names and functions but are new, simpler implementations.

.CW Who ,

for example, is a shell script, while

.CW ps

is just 95 lines of C code.

Some commands are essentially the same as their UNIX ancestors:

.CW awk ,

.CW troff ,

and others have been converted to ANSI C and extended to handle

Unicode, but are still the familiar tools.

Some are entirely new programs for old niches: the shell

.CW rc ,

text editor

.CW sam ,

debugger

.CW acid ,

and others

displace the better-known UNIX tools with similar jobs.

Finally, about half the commands are new.

.PP

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.

.SH

The File Server

.PP

A central file server stores permanent files and presents them to the network

as a file hierarchy exported using 9P.

The server is a stand-alone system, accessible only over the network,

designed to do its one job well.

It runs no user processes, only a fixed set of routines compiled into the

boot image.

Rather than a set of disks or separate file systems,

the main hierarchy exported by the server is a single

tree, representing files on many disks.

That hierarchy is

shared by many users over a wide area on a variety of networks.

Other file trees exported by

the server include

special-purpose systems such as temporary storage and, as explained

below, a backup service.

.PP

The file server has three levels of storage.

The central server in our installation has

about 100 megabytes of memory buffers,

27 gigabytes of magnetic disks,

and 350 gigabytes of

bulk storage in a write-once-read-many (WORM) jukebox.

The disk is a cache for the WORM and the memory is a cache for the disk;

each is much faster, and sees about an order of magnitude more traffic,

than the level it caches.

The addressable data in the file system can be larger than the size of the

magnetic disks, because they are only a cache;

our main file server has about 40 gigabytes of active storage.

.PP

The most unusual feature of the file server

comes from its use of a WORM device for

stable storage.

Every morning at 5 o'clock, a

.I dump

of the file system occurs automatically.

The file system is frozen and

all blocks modified since the last dump

are queued to be written to the WORM.

Once the blocks are queued,

service is restored and

the read-only root of the dumped

file system appears in a

hierarchy of all dumps ever taken, named by its date.

For example, the directory

.CW /n/dump/1995/0315

is the root directory of an image of the file system

as it appeared in the early morning of March 15, 1995.

It takes a few minutes to queue the blocks,

but the process to copy blocks to the WORM, which runs in the background, may take hours.

.PP

There are two ways the dump file system is used.

The first is by the users themselves, who can browse the

dump file system directly or attach pieces of

it to their name space.

For example, to track down a bug,

it is straightforward to try the compiler from three months ago

or to link a program with yesterday's library.

With daily snapshots of all files,

it is easy to find when a particular change was

made or what changes were made on a particular date.

People feel free to make large speculative changes

to files in the knowledge that they can be backed

out with a single

copy command.

There is no backup system as such;

instead, because the dump

is in the file name space, 

backup problems can be solved with

standard tools

such as

.CW cp ,

.CW ls ,

.CW grep ,

and

.CW diff .

.PP

The other (very rare) use is complete system backup.

In the event of disaster,

the active file system can be initialized from any dump by clearing the

disk cache and setting the root of

the active file system to be a copy

of the dumped root.

Although easy to do, this is not to be taken lightly:

besides losing any change made after the date of the dump, this recovery method

results in a very slow system.

The cache must be reloaded from WORM, which is much

slower than magnetic disks.

The file system takes a few days to reload the working

set and regain its full performance.

.PP

Access permissions of files in the dump are the same

as they were when the dump was made.

Normal utilities have normal

permissions in the dump without any special arrangement.

The dump file system is read-only, though,

which means that files in the dump cannot be written regardless of their permission bits;

in fact, since directories are part of the read-only structure,

even the permissions cannot be changed.

.PP

Once a file is written to WORM, it cannot be removed,

so our users never see

``please clean up your files''

messages and there is no

.CW df

command.

We regard the WORM jukebox as an unlimited resource.

The only issue is how long it will take to fill.

Our WORM has served a community of about 50 users

for five years and has absorbed daily dumps, consuming a total of

65% of the storage in the jukebox.

In that time, the manufacturer has improved the technology,

doubling the capacity of the individual disks.

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.

.SH

Unusual file servers

.PP

Plan 9 is characterized by a variety of servers that offer

a file-like interface to unusual services.

Many of these are implemented by user-level processes, although the distinction

is unimportant to their clients; whether a service is provided by the kernel,

a user process, or a remote server is irrelevant to the way it is used.

There are dozens of such servers; in this section we present three representative ones.

.PP

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

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:

programs running in a window see a set of files in

.CW /dev

with names like

.CW mouse ,

.CW screen ,

and

.CW cons .

Programs that want to print text to their window write to

.CW /dev/cons ;

to read the mouse, they read

.CW /dev/mouse .

In the Plan 9 style, bitmap graphics is implemented by providing a file

.CW /dev/bitblt

on which clients write encoded messages to execute graphical operations such as

.CW bitblt

(RasterOp).

What is unusual is how this is done:

8½ is a file server, serving the files in

.CW /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

.CW /dev .

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

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\(emit

multiplexes its own interface\(emso it may be run, recursively, as a client of itself.

Also, consider the implementation of

.CW /dev/tty

in UNIX, which requires special code in the kernel to redirect

.CW open

calls to the appropriate device.

Instead, in 8½ the equivalent service falls out

automatically: 8½ serves

.CW /dev/cons

as its basic function; there is nothing extra to do.

When a program wants to

read from the keyboard, it opens

.CW /dev/cons ,

but it is a private file, not a shared one with special properties.

Again, local name spaces make this possible; conventions about the consistency of

the files within them make it natural.

.PP

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.

Toggling once suspends client reads from the window;

toggling again resumes normal reads, which absorb whatever text has been prepared,

one line at a time.

This allows the user to edit multi-line input text on the screen before the application sees it,

obviating the need to invoke a separate editor to prepare text such as mail

messages.

A related property is that reads are answered directly from the

data structure defining the text on the display: text may be edited until

its final newline makes the prepared line of text readable by the client.

Even then, until the line is read, the text the client will read can be changed.

For example, after typing

.P1

% make

rm *

.P2

to the shell, the user can backspace over the final newline at any time until

.CW make

finishes, holding off execution of the

.CW rm

command, or even point with the mouse

before the

.CW rm

and type another command to be executed first.

.PP

There is no

.CW ftp

command in Plan 9.  Instead, a user-level file server called

.CW ftpfs

dials the FTP site, logs in on behalf of the user, and uses the FTP protocol

to examine files in the remote directory.

To the local user, it offers a file hierarchy, attached to

.CW /n/ftp

in the local name space, mirroring the contents of the FTP site.

In other words, it translates the FTP protocol into 9P to offer Plan 9 access to FTP sites.

The implementation is tricky;

.CW ftpfs

must do some sophisticated caching for efficiency and

use heuristics to decode remote directory information.

But the result is worthwhile:

all the local file management tools such as

.CW cp ,

.CW grep ,

.CW diff ,

and of course

.CW ls

are available to FTP-served files exactly as if they were local files.

Other systems such as Jade and Prospero

have exploited the same opportunity [Rao81, Neu92],

but because of local name spaces and the simplicity of implementing 9P,

this approach

fits more naturally into Plan 9 than into other environments.

.PP

One server,

.CW exportfs ,

is a user process that takes a portion of its own name space and

makes it available to other processes by

translating 9P requests into system calls to the Plan 9 kernel.

The file hierarchy it exports may contain files from multiple servers.

.CW Exportfs

is usually run as a remote server

started by a local program,

either

.CW import

or

.CW cpu .

.CW Import

makes a network call to the remote machine, starts

.CW exportfs

there, and attaches its 9P connection to the local name space.  For example,

.P1

import helix /net

.P2

makes Helix's network interfaces visible in the local

.CW /net

directory.  Helix is a central server and

has many network interfaces, so this permits a machine with one network to

access to any of Helix's networks.  After such an import, the local

machine may make calls on any of the networks connected to Helix.

Another example is

.P1

import helix /proc

.P2

which makes Helix's processes visible in the local

.CW /proc ,

permitting local debuggers to examine remote processes.

.PP

The

.CW cpu

command connects the local terminal to a remote

CPU server.

It works in the opposite direction to

.CW import :

after calling the server, it starts a

.I local

.CW exportfs

and mounts it in the name space of a process, typically a newly created shell, on the

server.

It then rearranges the name space

to make local device files (such as those served by

the terminal's window system) visible in the server's

.CW /dev

directory.

The effect of running a

.CW cpu

command is therefore to start a shell on a fast machine, one more tightly

coupled to the file server,

with a name space analogous

to the local one.

All local device files are visible remotely, so remote applications have full

access to local services such as bitmap graphics,

.CW /dev/cons ,

and so on.

This is not the same as

.CW rlogin ,

which does nothing to reproduce the local name space on the remote system,

nor is it the same as

file sharing with, say, NFS, which can achieve some name space equivalence but

not the combination of access to local hardware devices, remote files, and remote

CPU resources.

The

.CW cpu

command is a uniquely transparent mechanism.

For example, it is reasonable

to start a window system in a window running a

.CW cpu

command; all windows created there automatically start processes on the CPU server.

.SH

Configurability and administration

.PP

The uniform interconnection of components in Plan 9 makes it possible to configure

a Plan 9 installation many different ways.

A single laptop PC can function as a stand-alone Plan 9 system;

at the other extreme, our setup has central multiprocessor CPU

servers and file servers and scores of terminals ranging from small PCs to

high-end graphics workstations.

It is such large installations that best represent how Plan 9 operates.

.PP

The system software is portable and the same

operating system runs on all hardware.

Except for performance, the appearance of the system on, say,

an SGI workstation is the same

as on a laptop.

Since computing and file services are centralized, and terminals have

no permanent file storage, all terminals are functionally identical.

In this way, Plan 9 has one of the good properties of old timesharing systems, where

a user could sit in front of any machine and see the same system.  In the modern

workstation community, machines tend to be owned by people who customize them

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\(ema terminal

room\(emand a user may sit down at any one of them and work.

.PP

Central file servers centralize not just the files, but also their administration

and maintenance.

In fact, one server is the main server, holding all system files; other servers provide

extra storage or are available for debugging and other special uses, but the system

software resides on one machine.

This means that each program

has a single copy of the binary for each architecture, so it is

trivial to install updates and bug fixes.

There is also a single user database; there is no need to synchronize distinct

.CW /etc/passwd

files.

On the other hand, depending on a single central server does limit the size of an installation.

.PP

Another example of the power of centralized file service

is the way Plan 9 administers network information.

On the central server there is a directory,

.CW /lib/ndb ,

that contains all the information necessary to administer the local Ethernet and

other networks.

All the machines use the same database to talk to the network; there is no

need to manage a distributed naming system or keep parallel files up to date.

To install a new machine on the local Ethernet, choose a

name and IP address and add these to a single file in

.CW /lib/ndb ;

all the machines in the installation will be able to talk to it immediately.

To start running, plug the machine into the network, turn it on, and use BOOTP

and TFTP to load the kernel.

All else is automatic.

.PP

Finally,

the automated dump file system frees all users from the need to maintain

their systems, while providing easy access to backup files without

tapes, special commands, or the involvement of support staff.

It is difficult to overstate the improvement in lifestyle afforded by this service.

.PP

Plan 9 runs on a variety of hardware without

constraining how to configure an installation.

In our laboratory, we

chose to use central servers because they amortize costs and administration.

A sign that this is a good decision is that our cheap

terminals remain comfortable places

to work for about five years, much longer than workstations that must provide

the complete computing environment.

We do, however, upgrade the central machines, so

the computation available from even old Plan 9 terminals improves with time.

The money saved by avoiding regular upgrades of terminals

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.

.SH

C Programming

.PP

Plan 9 utilities are written in several languages.

Some are scripts for the shell,

.CW rc

[Duff90]; a handful

are written in a new C-like concurrent language called Alef [Wint95], described below.

The great majority, though, are written in a dialect of ANSI C [ANSIC].

Of these, most are entirely new programs, but some

originate in pre-ANSI C code

from our research UNIX system [UNIX85].

These have been updated to ANSI C

and reworked for portability and cleanliness.

.PP

The Plan 9 C dialect has some minor extensions,

described elsewhere [Pike95], and a few major restrictions.

The most important restriction is that the compiler demands that

all function definitions have ANSI prototypes

and all function calls appear in the scope of a prototyped declaration

of the function.

As a stylistic rule,

the prototyped declaration is placed in a header file

included by all files that call the function.

Each system library has an associated header file, declaring all

functions in that library.

For example, the standard Plan 9 library is called

.CW libc ,

so all C source files include

.CW <libc.h> .

These rules guarantee that all functions

are called with arguments having the expected types \(em something

that was not true with pre-ANSI C programs.

.PP

Another restriction is that the C compilers accept only a subset of the

preprocessor directives required by ANSI.

The main omission is

.CW #if ,

since we believe it

is never necessary and often abused.

Also, its effect is

better achieved by other means.

For instance, an

.CW #if

used to toggle a feature at compile time can be written

as a regular

.CW if

statement, relying on compile-time constant folding and

dead code elimination to discard object code.

.PP

Conditional compilation, even with

.CW #ifdef ,

is used sparingly in Plan 9.

The only architecture-dependent

.CW #ifdefs

in the system are in low-level routines in the graphics library.

Instead, we avoid such dependencies or, when necessary, isolate

them in separate source files or libraries.

Besides making code hard to read,

.CW #ifdefs

make it impossible to know what source is compiled into the binary

or whether source protected by them will compile or work properly.

They make it harder to maintain software.

.PP

The standard Plan 9 library overlaps much of

ANSI C and POSIX [POSIX], but diverges

when appropriate to Plan 9's goals or implementation.

When the semantics of a function

change, we also change the name.

For instance, instead of UNIX's

.CW creat ,

Plan 9 has a

.CW create

function that takes three arguments,

the original two plus a third that, like the second

argument of

.CW open ,

defines whether the returned file descriptor is to be opened for reading,

writing, or both.

This design was forced by the way 9P implements creation,

but it also simplifies the common use of

.CW create

to initialize a temporary file.

.PP

Another departure from ANSI C is that Plan 9 uses a 16-bit character set

called Unicode [ISO10646, Unicode].

Although we stopped short of full internationalization,

Plan 9 treats the representation

of all major languages uniformly throughout all its

software.

To simplify the exchange of text between programs, the characters are packed into

a byte stream by an encoding we designed, called UTF-8,

which is now

becoming accepted as a standard [FSSUTF].

It has several attractive properties,

including byte-order independence,

backwards compatibility with ASCII,

and ease of implementation.

.PP

There are many problems in adapting existing software to a large

character set with an encoding that represents characters with

a variable number of bytes.

ANSI C addresses some of the issues but

falls short of

solving them all.

It does not pick a character set encoding and does not

define all the necessary I/O library routines.

Furthermore, the functions it

.I does

define have engineering problems.

Since the standard left too many problems unsolved,

we decided to build our own interface.

A separate paper has the details [Pike93].

.PP

A small class of Plan 9 programs do not follow the conventions

discussed in this section.

These are programs imported from and maintained by

the UNIX community;

.CW tex

is a representative example.

To avoid reconverting such programs every time a new version

is released,

we built a porting environment, called the ANSI C/POSIX Environment, or APE [Tric95].

APE comprises separate include files, libraries, and commands,

conforming as much as possible to the strict ANSI C and base-level

POSIX specifications.

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.

.SH

Portability and Compilation

.PP

Plan 9 is portable across a variety of processor architectures.

Within a single computing session, it is common to use

several architectures: perhaps the window system running on

an Intel processor connected to a MIPS-based CPU server with files

resident on a SPARC system.

For this heterogeneity to be transparent, there must be conventions

about data interchange between programs; for software maintenance

to be straightforward, there must be conventions about cross-architecture

compilation.

.PP

To avoid byte order problems,

data is communicated between programs as text whenever practical.

Sometimes, though, the amount of data is high enough that a binary

format is necessary;

such data is communicated as a byte stream with a pre-defined encoding

for multi-byte values.

In the rare cases where a format

is complex enough to be defined by a data structure,

the structure is never

communicated as a unit; instead, it is decomposed into

individual fields, encoded as an ordered byte stream, and then

reassembled by the recipient.

These conventions affect data

ranging from kernel or application program state information to object file

intermediates generated by the compiler.

.PP

Programs, including the kernel, often present their data

through a file system interface,

an access mechanism that is inherently portable.

For example, the system clock is represented by a decimal number in the file

.CW /dev/time ;

the

.CW time

library function (there is no

.CW time

system call) reads the file and converts it to binary.

Similarly, instead of encoding the state of an application

process in a series of flags and bits in private memory,

the kernel

presents a text string in the file named

.CW status

in the 

.CW /proc

file system associated with each process.

The Plan 9

.CW ps

command is trivial: it prints the contents of

the desired status files after some minor reformatting; moreover, after

.P1

import helix /proc

.P2

a local

.CW ps

command reports on the status of Helix's processes.

.PP

Each supported architecture has its own compilers and loader.

The C and Alef compilers produce intermediate files that

are portably encoded; the contents

are unique to the target architecture but the format of the

file is independent of compiling processor type.

When a compiler for a given architecture is compiled on

another type of processor and then used to compile a program

there,

the intermediate produced on

the new architecture is identical to the intermediate

produced on the native processor.  From the compiler's

point of view, every compilation is a cross-compilation.

.PP

Although each architecture's loader accepts only intermediate files produced

by compilers for that architecture,

such files could have been generated by a compiler executing

on any type of processor.

For instance, it is possible to run

the MIPS compiler on a 486, then use the MIPS loader on a

SPARC to produce a MIPS executable.

.PP

Since Plan 9 runs on a variety of architectures, even in a single installation,

distinguishing the compilers and intermediate names

simplifies multi-architecture

development from a single source tree.

The compilers and the loader for each architecture are

uniquely named; there is no

.CW cc

command.

The names are derived by concatenating a code letter

associated with the target architecture with the name of the

compiler or loader.  For example, the letter `8' is

the code letter for Intel

.I x 86

processors; the C compiler is named

.CW 8c ,

the Alef compiler

.CW 8al ,

and the loader is called

.CW 8l .

Similarly, the compiler intermediate files are suffixed

.CW .8 ,

not

.CW .o .

.PP

The Plan 9

build program

.CW mk ,

a relative of

.CW make ,

reads the names of the current and target

architectures from environment variables called

.CW $cputype

and

.CW $objtype .

By default the current processor is the target, but setting

.CW $objtype

to the name of another architecture

before invoking

.CW mk