Plan9 Operating System: Ashish Ranjan

PLAN9 OPERATING SYSTEM
A SEMINAR REPORT
Submitted by
ASHISH RANJAN
in partial fulfillment for the award of the degree
of
BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE & ENGINEERING
SCHOOL OF ENGINEERING
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
COCHIN – 682022
SEPTEMBER 2008
DIVISION OF COMPUTER SCIENCE AND ENGINEERING
SCHOOL OF ENGINEERING
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
COCHIN – 682022
Certificate
Certified that this is bonafide record of seminar entitled
Plan9 Operating System
Presented by following student
ASHISH RANJAN
Of the VIIth semester ,Computer Science and Engineering in the year 2008 in the
partial fulfillment of the requirements to the award of Degree of Bachelor of
Technology in Computer Science of Engineering of Cochin University of Science
and Technology.
LATA NAIR Dr. David Peter S

Seminar Guide Head of the Department
Computer Science and Engineering, Computer Science and Engineering,
School of Engineering. School of Engineering.
Date:
ACKNOWLEDGEMENT
It is with greatest pleasure and pride that I present this report before you. At this
moment of triumph, it would be unfair to neglect all those who helped me in the
successful completion of this seminar.
First of all, I would like to place myself at the feet of God Almighty for his
everlasting love and for the blessings & courage that he gave me, which made it
possible to me to see through the turbulence and to set me in the right path.
I would also like to thank our Head of the Department, Mr. David Peter S for all
the help and guidance that she provided to me.
I am grateful to my seminar guide, Lata Nair ,for his guidance and whole
hearted support and very valued constructive criticism that has driven to complete
the seminar successfully.
I would take this opportunity to thank my friends who were always a source of
encouragement.
i
ABSTRACT
Plan 9 from Bell Labs is a distributed operating system, primarily used as a

research vehicle. It was developed as the research successor to Unix by the
Computing Sciences Research Center at Bell Labs between the mid-1980s and
2002. Plan 9 replaced Unix at Bell Labs as the organization's primary platform for
research and explores several changes to the original Unix model that improve the
experience of using and programming the system, notably in distributed multi-user
environments. One of the key features a.dopted from Unix was the use of the file
system to access resources. Plan 9 is an operating system kernel but also a
collection of accompanying software. The bulk of the software is predominantly
new, written for Plan 9 rather than ported from Unix or other systems. The window
system, compilers, file server, and network services are all freshly written for Plan
9.Plan 9's designers were interested in goals similar to those of microkernels , but
made different architecture and design choices to achieve them. Plan 9's design
goals included:
Resources as files: all resources are represented as files within a

hierarchical file system
Namespaces: the application view of the network is a single, coherent

namespace that appears as a hierarchical file system but may represent
physically separated (locally or remotely) resources
Standard communication protocol: a standard protocol, called 9P, is

used to access all resources, both local and remote
ii
Table of Contents
Chapter Title Page

No. No.
1 Introduction to Plan9 1
2 Introduction to Unix 2
3 Installation of Plan9 3
4 Configurability And Administration 5
5 Design Issues Of Plan9 7
5.1 Resources As Files 7
5.2 Namespaces 7
5.3 Standard communication protocol 8
6 The Command-Level View 9
7 Plan9 File System 11
8 The File Server 13
9 File Caching 15
10 File Permissions 16
11 Organisation Of Network In Plan9 18

11.1 Kernel Network Support 18
11.2 The File System Protocol 18
11.3 Kernel Organization 19
12 Kernel Structure For Network 21
13 Portability And Compilation 22
14 Parallel Programming 25
15 Hardware Requirements 26
16 Features Of Plan9 29
17 Performance 30
18 Applications of Plan9 31
19 Conclusion 32
20 References 33
List of figures
Sl. No. Images Page No.

1 Installation 3
2 Kernel Organization 21
1 INTRODUCTION TO PLAN9
It was developed as the research successor to Unix by the Computing Sciences
Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 replaced
Unix at Bell Labs as the organization's primary platform for research and explores
several changes to the original Unix model that improve the experience of using and
programming the system, notably in distributed multi-user environments. Plan 9
from Bell Labs is a distributed operating system.
One of the key features adopted from Unix was the use of the file system to
access resources. Plan 9 is an operating system , system kernel but also a collection
of accompanying software. The bulk of the software is predominantly new, written
for Plan 9 rather than ported from Unix or other systems. The window compilers ,
file server, and network services are all freshly written for Plan 9.
Plan 9 is most notable for representing all system interfaces, including those
required for networking and the user-interface, through the file system rather than
specialized interfaces. Plan 9 aims to provide users with a workstation-independent
working environment through the use of the 9P protocols. Plan 9 continues to be
used and developed in some circles as a research operating system and by hobbyists.
Division of Computer Science & Engineering, SOE, CUSAT 1

2 INTRODUCTION TO UNIX
Unix (officially trademarked as UNIX®) is a computer operating system originally
developed in 1969 by a group of AT&T employees at Bell Labs including Ken
Thompson, Dennis Ritchie and Douglas McIlroy. Today's Unix systems are split
into various branches, developed over time by AT&T as well as various commercial
vendors and non-profit organizations.
As of 2007, the owner of the trademark UNIX® is The Open Group, an
industry standards consortium. Only systems fully compliant with and certified to
the Single UNIX Specification qualify as "UNIX®" (others are called "Unix
system-like" or "Unix-like").
During the late 1970s and early 1980s, Unix's influence in academic circles
led to large-scale adoption of Unix (particularly of the BSD variant, originating
from the University of California, Berkeley) by commercial startups, the most
notable of which is Sun Microsystems. Today, in addition to certified Unix systems,
Unix-like operating systems such as Linux and BSD derivatives are commonly
encountered.Sometimes, "traditional Unix" may be used to describe a Unix or an
operating system that has the characteristics of either Version 7 Unix or UNIX
System V.

3 INSTALLATION OF PLAN9
Figure 1. INSTALLATION

When a terminal is powered on, it must be told the name of a file server to boot
from, the operating system kernel to boot, and a user name and password. Once it is
complete, the terminal loads the Plan 9 kernel, which sets some environment
variables and builds an initial namespace from the user input (‘$cputype’,
‘$objtype’, ‘$user’, ‘$home’, union of ‘/$cputype/bin’ and ‘/rc/bin’ into ‘/bin’).
Eventually, the terminal runs ‘rc’ on ‘/usr/$user/lib/profile’. The user name
becomes the terminal’s ID. The password is converted into a 56-bit DES key and
saved as the machine key.
When a CPU or a file server boots, it reads a key, an ID, and a domain name
from non-volatile RAM. This allows the servers to reboot without one operator
intervention.
A terminal runs programs depending on how it uses resources (e.g., heavy
computations on a CPU server, frequent file I/O close to the file system). A call to
the command ‘cpu’ starts an ‘rc’ shell on a CPU server. ‘cpu’ is invoked in a ‘rio’
window. Standard input, output, and error files are connected to the ‘/dev/cons’ in
the namespace where the ‘cpu’ command was invoked.
The namespace for the new ‘rc’ is similar to the one from which the ‘cpu’
command was invoked; only architecture-dependent bindings such as ‘/bin’ may
change; CPU-local devices such as fast file systems are still local; only terminal-
local devices are imported; the terminal becomes a file server of the CPU. The result
is different from ‘rlogin’ which moves to a distinct namespace.The result is different
from NFS which keeps the namespace but runs the process locally.

4 CONFIGURABILITY AND ADMINISTRATION
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
standard 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.
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 use 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.
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/etc/password files. On the other hand, depending on a single central server
does limit the size of an installation.
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, /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 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 /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.
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.
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.

5 DESIGN ISSUES OF PLAN9

Plan 9's designers were interested in goals similar to those of micro kernels,
but made different architecture and design choices to achieve them. Plan 9's
design goals included:
5.1 Resources as files: all resources are represented as files within a
hierarchical file system Plan 9 extended the system beyond files to "names", that
is, a unique path to any object whether it be a file, screen, user, or computer. All
were handled using the existing Unix standards, but extended such that any
object could be named and addressed (similar in concept to the more widely
known URI system of the world wide web). In Unix, devices such as printers
had been represented by names using software converters in /dev, but these
addressed only devices attached by hardware, and did not address networked
devices. Under Plan 9 printers were as virtualized as files, and both could be
accessed over the network from any workstation.Another Plan 9 innovation was
the ability for users to have different names for the same "real world" objects.
Each user could create a personalized environment by collecting various objects
into their namespace. Unix has a similar concept in which users gain privileges
by being copied from another user, but Plan 9 extends this to all objects.
5.2 Namespaces: the application view of the network is a single, coherent
namespace that appears as a hierarchical file system but may represent
physically separated (locally or remotely) resources.Namespace is an abstract
container providing context for the items (names, or technical terms, or words) it
holds and allows disambiguation of items having the same name (residing in
different namespaces).As a rule, names in a namespace cannot have more than
one meaning, that is, two or more things cannot share the same name. A
namespace is also called a context, as the valid meaning of a name can change
depending on what namespace applies. Names in it can represent objects as well
as concept, whether it is a natural or ethnic language, a constructed language,
the technical terminology of a profession, a dialect, a sociolect, or an artificial
language (e.g., a programming language)

For many programming languages, a namespace is a context for identifiers.

In an operating system, an example of namespace is a directory. It contains items
which must have unique names. In the Java programming language, items that
appear in namespaces have a short (local) name and unique long "qualified" names
for use outside the name space. Also, some languages (such as C) combine
namespace and names in a process called name mangling in order to eradicate
ambiguity.
5.3 Standard communication protocol: a standard protocol, called 9P, is used to
access all resources, both local and remote . 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].
9P (or the Plan 9 Filesystem Protocol or Styx), is a network protocol developed for
the Plan9 from Bell Labs distributed operating system as the means of connecting
the components of a Plan 9 system. Files are key objects in Plan 9. They represent
windows, network connections, processes, and almost anything else available in the
operating system. 9P encourages caching and also serving of synthetic files (e.g.
/proc to represent processes), unlike NFS. 9P was revised for the 4th edition of Plan
9 under the name 9P2000 that contained various fundamental improvements. The
latest version of Inferno also uses 9P2000. The Inferno file protocol was originally
called Styx, but technically it has always been a variant of 9P.
There is a server implementation of 9P for Unix called u9fs included in the
Plan 9 distribution, and a kernel client driver for Linux as part of the v9fs project.
9P (and derivatives) have also found application in embedded environments, such as
the Styx on a Brick project.

6 THE COMMAND-LEVEL VIEW

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.
Each window is created in a separate name space. Adjustments made to the
namespace 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.
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 /dev/mouse, /dev/bitblt, and
/dev/cons (analogous to UNIX_s /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 a remote 8½ application
sees the mouse, bitblt, and cons files for the window as us- ual in /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.
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 ls,
cat, and who have familiar names and functions but are new, simpler
implementations. Who, for example, is a shell script, while ps is just 95 lines of C
code. Some commands are essentially the same as their UNIX ancestors: awk, 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 rc,
text editor sam, debugger acid, and others displace the better-known UNIX tools
with similar jobs. Finally, about half the commands are new.

7 PLAN9 FILE SYSTEM

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.
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.
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 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
/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.
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 cp, ls, grep, and diff.
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.
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.
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 df command. We regard
the WORM jukebox as an unlimited resource. The only issue is how long it will
take to fill.

8 THE FILE SERVER

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..
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.
device for stable storage. Every morning at 5 o’clock, a dump of the file system
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
take hours.
device for stable storage. Every morning at 5 o’clock, a dump of the file system

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
take hours.
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 namespace. 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 cp, ls, grep, and diff
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.
.

9 FILE CACHING
The 9P protocol has no explicit support for caching files on a client. The large
memory of the central file server acts as a shared cache for all its clients, which
reduces the total amount of memory needed across all machines in the network.
Nonetheless, there are sound reasons to cache files on the client, such as a slow
connection to the file server.
The version field of the qid is changed whenever the file is modified, which
makes it possible to do some weakly coherent forms of caching. The most important
is client caching of text and data segments of executable files. When a process execs
a program, the file is re-opened and the qid’s version is compared with that in the
cache; if they match, the local copy is used. The same method can be used to build a
local caching file server. 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 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.

10 FILE PERMISSIONS
One of the advantages of constructing services as file systems is that the solutions to
ownership and permission problems fall out naturally. As in UNIX, each file
ordirectory has separate read, write, and execute/search permissions for the file
owner, the file’s group, and anyone else. The idea of group is unusual: any user nam
is potentially a group name. A group is just a user with a list of other users in the
group. Conventions make the distinction: most people have user names without
group members, while groups have long lists of attached names. For example, the
sys group traditionally has all the system programmers, and system files are
accessible by group sys. Consider the following two lines of a user database stored
on a server:
PJW:PJW:
SYS::PJW,KEN,PHILW,PRESOTTO
The first establishes user pjw as a regular user. The second establishes user sys as a
group and lists four users who are members of that group. The empty colon-
separated field is space for a user to be named as the group leader. If a group has a
leader, that user has special permissions for the group, such as freedom to change
the group permissions of files in that group. If no leader is specified, each member
of the group is considered equal, as if each were the leader. In our example, only
pjw can add members to his group, but all of system’s members are equal partners
in that group. Regular files are owned by the user that creates them. The group name
is inherited from the directory holding the new file. Device files are treated
specially: the kernel may arrange the ownership and permissions of a file
appropriate to the user accessing the file.
A good example of the generality this offers is process files which are owned
and read-protected by the owner of the process. If the owner wants to let someone
else access the memory of a process, for example to let the author of a program
debug a broken image, the standard chmod command applied to the process files
does the job.Another unusual application of file permissions is the dump file system,
which is not only served by the same file server as the original data, but represented
by the same user database. Files in the dump are therefore given identical protection
as files in the regular file system; if a file is owned by pjw and read-protected, once
it is in the dump file system it is still owned by pjw and read-protected. Also, since

the dump file system is immutable, the file cannot be changed; 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 reuse.

11 ORGANISATION OF NETWORK IN PLAN9

11.1 Kernel Network Support
Networks play a central role in any distributed system. This is particularly true in
Plan 9 where most resources are provided by servers external to the kernel. The
importance of the networking code within the kernel is reflected by its size; of
25,000 lines of kernel code, 12,500 are network and protocol related. Networks are
continually being added and the fraction of code devoted to communications is
growing. Moreover, the network code is complex. Protocol implementations consist
almost entirely of synchronization and dynamic memory management, areas
demanding subtle error recovery strategies. The kernel currently supports Datakit,
point-to-point fiber links, an Internet (IP) protocol suite and ISDN data service. The
variety of networks and machines has raised issues not addressed by other systems
running on commercial hardware supporting only Ethernet or FDDI.
11.2 The File System protocol
A central idea in Plan 9 is the representation of a resource as a hierarchical file
system. Each process assembles a view of the system by building a name space
[Needham] connecting its resources. File systems need not represent disc files; in
fact, most Plan 9 file systems have no permanent storage. A typical file system
dynamically represents some resource like a set of network connections or the
process table. Communication between the kernel, device drivers, and local or
remote file servers uses a protocol called 9P. The protocol consists of 17 messages
describing operations on files and directories. Kernel resident device and protocol
drivers use a procedural version of the protocol while external file servers use an
RPC form. Nearly all traffic between Plan 9 systems consists of 9P messages. 9P
relies on several properties of the underlying transport protocol. It assumes messages
arrive reliably and in sequence and that delimiters between messages are preserved.
When a protocol does not meet these requirements (for example, TCP does not
preserve delimiters) we provide mechanisms to marshal messages before handing
them to the system transport protocol. It assumes messages arrive reliably and in
sequence and that delimiters between messages are preserved. When a protocol does
not meet these requirements (for example, TCP does not preserve delimiters) we
provide mechanisms to marshal messages before handing them to the system.

A kernel data structure, the channel, is a handle to a file server. Operations on

a channel generate the following 9P messages. The session and attach messages
authenticate a connection, established by means external to 9P, and validate its user.
The result is an authenticated channel referencing the root of the server. The clone
message makes a new channel identical to an existing channel, much like the dup
system call. A channel may be moved to a file on the server using a walk message to
descend each level in the hierarchy. The stat and wstat messages read and write the
attributes of the file referenced by a channel. The open message prepares a channel
for subsequent read and write messages to access the contents of the file. Create and
remove perform the actions implied by their names on the file referenced by the
channel. The clunk message discards a channel without affecting the file.A kernel
resident file server called the mount driver converts the procedural version of 9P
into RPCs. The mount system call provides a file descriptor, which can be a pipe to
a user process or a network connection to a remote machine, to be associated with
the mount point. After a mount, operations on the file tree below the mount point
are sent as messages to the file server. The mount driver manages buffers, packs and
unpacks parameters from messages, and demultiplexes among processes using the
file server
11.3 Kernel Organization
The network code in the kernel is divided into three layers: hardware
interface, protocol processing, and program interface. A device driver typically uses
streams to connect the two interface layers. Additional stream modules may be
pushed on a device to process protocols. Each device driver is a kernel-resident file
system. Simple device drivers serve a single level directory containing just a few
files; for example, we represent each UART by a data and a control file.
cpu%Â cdÂ /dev
cpu%Â lsÂ -lÂ eia*
--rw-rw-rw-Â tÂ 0Â bootesÂ bootesÂ 0Â JulÂ 16Â 17:28
Â eia1
--rw-rw-rw-
Â tÂ 0Â bootesÂ bootesÂ 0Â JulÂ 16Â 17:28Â eia1ctl
--rw-rw-rw-Â tÂ 0Â bootesÂ bootesÂ 0Â JulÂ 16Â 17:28
Â eia2

--rw-rw-rw-Â tÂ 0Â bootesÂ bootesÂ 0Â JulÂ 16Â 17:28Â ei

a2ctl
cpu%
The control file is used to control the device; writing the string b1200 to /dev/eia1ctl
sets the line to 1200 baud.
Multiplexed devices present a more complex interface structure. For example, the
LANCE Ethernet driver serves a two level file tree (Figure 1) providing
∙ device control and configuration
∙ user-level protocols like ARP
∙ diagnostic interfaces for snooping software.
The top directory contains a clone file and a directory for each connection,
numbered 1 to n. Each connection directory corresponds to an Ethernet packet type.
Opening the clone file finds an unused connection directory and opens its ctl file.
Reading the control file returns the ASCII connection number; the user process can
use this value to construct the name of the proper connection directory. In each
connection directory files named ctl, data, stats, and type provide access to the
connection. Writing the string connect 2048 to the ctl file sets the packet type to
2048 and configures the connection to receive all IP packets sent to the machine.
Subsequent reads of the file type yield the string 2048. The data file accesses the
media; reading it returns the next packet of the selected type. Writing the file queues
a packet for transmission after appending a packet header containing the source
address and packet type. The stats file returns ASCII text containing the interface
address, packet input/output counts, error statistics, and general information about
the state of the interface.

Figure 2 Kernel Organization
If several connections on an interface are configured for

a particular packet type, each receives a copy of the incoming packets. The special
packet type -1 selects all packets. Writing the strings promiscuous and connect -1
to the ctl file configures a conversation to receive all packets on the Ethernet.

12 KERNEL STRUCTURE FOR NETWORK

The kernel plumbing used to build Plan 9 communications channels is called
streams [Rit84][Presotto]. A stream is a bidirectional channel connecting a physical
or pseudo-device to a user process. The user process inserts and removes data at one
end of the stream; a kernel process acting on behalf of a device operates at the other
end. A stream comprises a linear list of processing modules. Each module has both
an upstream (toward the process) and downstream (toward the device) put routine.
Calling the put routine of the module on either end of the stream inserts data into the
stream.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.

13 PORTABILITY AND COMPILATION

Plan 9 is portable across a variety of processor architectures. Within a single com-
puting 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 straight forward, there must be conventions about cross-
architecture compilation.
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.
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 /dev/time; the time library
function (there is no 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 status
in the /proc file system associated with each process. The Plan 9 ps command is
trivial: it prints the contents of the desired status files after some minor reformatting;
moreover, after import helix /proc a local ps command reports on the status of
Helix’s processes.
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.
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.

14 PARALLEL PROGRAMMING
Plan 9_s support for parallel programming has two aspects. First, the kernel
provides a simple process model and a few carefully designed system calls for
synchronization and sharing. Second, a new parallel programming language called
Alef supports concurrent programming. Although it is possible to write parallel
programs in C, Alef is the parallel language of choice.
There is a trend in new operating systems to implement two classes of
processes: normal UNIX-style processes and light-weight kernel threads. Instead,
Plan 9 provides a single class of process but allows fine control of the sharing of a
process_s resources such as memory and file descriptors. A single class of process is
a feasible approach in Plan 9 because the kernel has an efficient system call
interface and cheap process creation and scheduling Parallel
programs have three basic requirements: management of resources shared between
processes, an interface to the scheduler, and fine-grain process synchronization
using spin locks. On Plan 9, new processes are created using the rfork system call.
Rfork takes a single argument, a bit vector that specifies which of the parent
process_s resources should be shared, copied, or created anew in the child. The
resources controlled by rfork include the name space, the environment, the file
descriptor table, memory segments, and notes (Plan 9_s analog of UNIX signals).
One of the bits controls whether the rfork call will create a new process; if the bit is
off, the resulting modification to the resources occurs in the process making the call.
For example, a process calls rfork(RFNAMEG) to disconnect its name space from
its parents. Alef uses a fine-grained fork in which all the resources, including
memory, are shared between parent and child, analogous to creating a kernel thread
in many systems An
indication that rfork is the right model is the variety of ways it is used. Other than
the canonical use in the library routine fork, it is hard to find two calls to 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 processes_regular processes
and threads_could not handle this variety.

15 HARDWARE REQUIREMENTS
IDE/ATAPI CONTROLLERS
Plan 9 supports almost all motherboard IDE/ATAPI controllers, but DMA transfers
are only used on these recognized chipsets (chipsets not listed here will simply run
slower; you can try turning on DMA by editing /sys/src/9/pc/sdata.c).
-AMD 768, 3111
-CMD 640B, 646
-HighPoint HPT366
-Intel PIIX, PIIX3, PIIX4, ICH, ICH0, ICH2-6
-NS PC87415
-nVidia nForce 1, nForce 2, nForce 3, nForce 4
-PC-Tech RZ1000
-Promise PDC202xx, Ultra/133 TX2, 20378
-ServerWorks IB6566
-SiL 3112 SATA, 3114 SATA/RAID
-ATI 4379 SATA
-SiS 962
-VIA 82C686, VT8237 SATA/RAID
-SCSI CONTROLLERS
-Buslogic BT-948 or BT-958 (AKA Mylex multimaster series). These aren't being
made any more, but you might be able to buy them used.
Adaptec 1540 or 1542 for the ISA bus
Ultrastor 14F ISA or 34F VLB
USB
Intel's UHCI interface is supported, but it only supports USB 1 (12Mb/s) devices.
Support for the alternative OHCI interface is in progress. EHCI (USB 2, 480Mb/s)
support has not been started but is likely to follow before long, since plugging a
USB 2 device (e.g., disk) into a system containing an EHCI controller causes all
USB traffic to be routed to the EHCI controller, despite the presence of UHCI or
OHCI controllers

ETHERNET
Plan 9 will automatically recognize the PCI Ethernet cards that it can drive. The
following chips/cards are supported
3Com 3C562, 3C589, and 3C589E PCMCIA
3Com 3C450, 3C575, 3C59x, 3C90x, 3CSOHO100-TX
-Accton EtherPair-PCMCIA EN2216
-Alteon, DEC, or SGI Acenic fiber Gigabi
-AMD 79C97
-D-Link DFE-538TX, DFE-560TXD
-Dell TrueMobile 1150 wireless
-Digital (now Intel) 2114x and clones. (Tulip, PIC, PIC-II, Centaur, Digital
-DE-500)
-EtherFast 10/100 PC Card
-Intel 82562EM/EZ/ET/VE, 8255x PRO/100
-Intel 8254x PRO/1000 Gigabit
-Intersil Prism2.5 wireless
-Linksys EC2T Combo PCMCIA EtherCard, NB10T
-Linksys WPC-11 wireless
-Lucent/Agere/Avaya/Orinoco Wavelan wireless
-NE2000 clones

-National Semiconductor DP83815, DP8390

-National Semiconductor DP83820 Gigabit
-Netgear FA310, FA311, FA312, FA410TX, FA411 PCMCIA
-Netgear GA620 Gigabit
-Realtek 8029, 8110S/8169S, 8139
KEYBOARDS
Any PS/2 keyboard should work. USB keyboards might work if you can enable PS/
2 "emulation" in your BIOS.

16 FEATURES OF PLAN9
Plan 9 is designed around the basic principle that all resources appear as files in a
hierarchical file system (namespace) which is unique to each process. These
resources are accessed via a network-level protocol called 9P which hides the exact
location of services from the user. All servers provide their services as an exported
hierarchy of files
Features
-The dump file system makes a daily "snapshot" of the filestore available to users
-Unicode character set support throughout the system
-Advanced kernel synchronization facilities for parallel processing
-ANSI/POSIX environment emulator (APE)
-Plumbing, a language driven way for applications to communicate
-Acme - an editor, shell and window system for programmers
-Sam - a screen editor with structural regular expressions
-Support for MIME mail messages and IMAP4
-Security - there is no super-user or root, and passwords are never sent over the
network
-Venti - archival storage
-Fossil - Hierarchical file system built on top of Venti, with automatic snapshots and
archives

17 PERFORMANCE
As a simple measure of the performance of the Plan 9 kernel, we compared the time
to do some simple operations on Plan 9 and on SGI_s IRIX Release 5.3 running on
an SGI Challenge M with a 100MHz MIPS R4400 and a 1-megabyte secondary
cache. The test program was written in Alef, compiled with the same compiler, and
run on identical hardware, so the only variables are the operating system and
libraries.The program tests the time to do a context switch (rendezvous on Plan
9,blockproc on IRIX); a trivial system call (rfork(0) and nap(0)); and
lightweightfork (rfork(RFPROC) and sproc(PR_SFDS|PR_SADDR)). It also
measures the time to send a byte on a pipe from one process to another and the
throughput on a pipe
TEST PLAN9 IRIX

CONTEX SWITCH 39µs 150 µs
SYSTEM CALL 6 µs 36 µs
LIGHT FORK 1300 µs 2200 µs
PIPE LATENCY 1100 µs 200 µs
PIPE BANDWIDTH 11678 KB/s 14545 KB/s
Performance comparison.

18 APPLICATIONS OF PLAN9
18.1 Inferno System
An OS that combines the system structure ideas from Plan 9 with other ideas:
-A virtual operating system that can run either stand-alone on a small
device (hand-held, or set-top box, games console)
-Or as an ordinary application under Windows, Unix, etc.
By chance and circumstance, similar for portable languages and systems were
also re-emerging with Java language technology
18.2 Lucent Managed Firewalls

-An Internet-to-Intranet safety interface, with packet and content filtering
-Uses Inferno as its internal operating system for its central element: the
“brick”.
18.3 Viaduct
-A small box (15 cm long) provides VPN (Virtual Private Network) secure
tunneling for homes or small offices
-Does encryption and compression
-Intended for DSL and cable modem connections
no administration needed--just insert between modem and computer
-Uses Plan 9 as its operating system
-Not a product: used mainly in research group

19 CONCLUSION
-The line of research has been highly fruitful

-Unix and its offspring have been successful and influential (especially lively today
in Linux)
-Adoption of our technology is pervasive throughout the computer world
-It still continues: but the challenge for Bell Labs research is to continue to find the
new and interesting places in which to work

20 REFERENCES
Plan 9 Programmer's Manual, Volume 1,
T.J. Killian, “Processes as Files”
B. Clifford Neuman, “The Prospero File System”
http://en.wikipedia.org/wiki/Comparison_of_operating_systems

Plan9 Operating System: Ashish Ranjan

Uploaded by

Copyright:

Available Formats

Plan9 Operating System: Ashish Ranjan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Plan9 Operating System: Ashish Ranjan

Uploaded by

Copyright:

Available Formats

PLAN9 OPERATING SYSTEM

in partial fulfillment for the award of the degree

COMPUTER SCIENCE & ENGINEERING

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY

Certified that this is bonafide record of seminar entitled

Plan9 Operating System

Presented by following student

LATA NAIR Dr. David Peter S

successful completion of this seminar.

the help and guidance that she provided to me.

the seminar successfully.

Plan 9 from Bell Labs is a distributed operating system, primarily used as a

Resources as files: all resources are represented as files within a

Namespaces: the application view of the network is a single, coherent

Standard communication protocol: a standard protocol, called 9P, is

Chapter Title Page

7 Plan9 File System 11

8 The File Server 13

11 Organisation Of Network In Plan9 18

13 Portability And Compilation 22

Sl. No. Images Page No.

Division of Computer Science & Engineering, SOE, CUSAT 1

Division of Computer Science & Engineering, SOE, CUSAT 2

Division of Computer Science & Engineering, SOE, CUSAT 3

Division of Computer Science & Engineering, SOE, CUSAT 4

4 CONFIGURABILITY AND ADMINISTRATION

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

Division of Computer Science & Engineering, SOE, CUSAT 5

Division of Computer Science & Engineering, SOE, CUSAT 6

5 DESIGN ISSUES OF PLAN9

Division of Computer Science & Engineering, SOE, CUSAT 7

For many programming languages, a namespace is a context for identifiers.

Division of Computer Science & Engineering, SOE, CUSAT 8

6 THE COMMAND-LEVEL VIEW

Division of Computer Science & Engineering, SOE, CUSAT 9

Division of Computer Science & Engineering, SOE, CUSAT 10

7 PLAN9 FILE SYSTEM

Division of Computer Science & Engineering, SOE, CUSAT 11

Division of Computer Science & Engineering, SOE, CUSAT 12

8 THE FILE SERVER

Division of Computer Science & Engineering, SOE, CUSAT 13

Division of Computer Science & Engineering, SOE, CUSAT 14

Division of Computer Science & Engineering, SOE, CUSAT 15

Division of Computer Science & Engineering, SOE, CUSAT 16

Division of Computer Science & Engineering, SOE, CUSAT 17

11 ORGANISATION OF NETWORK IN PLAN9

Division of Computer Science & Engineering, SOE, CUSAT 18

A kernel data structure, the channel, is a handle to a file server. Operations on

Division of Computer Science & Engineering, SOE, CUSAT 19

--rw-rw-rw-Â tÂ 0Â bootesÂ bootesÂ 0Â JulÂ 16Â 17:28Â ei

Division of Computer Science & Engineering, SOE, CUSAT 20

Figure 2 Kernel Organization

If several connections on an interface are configured for

Division of Computer Science & Engineering, SOE, CUSAT 21

12 KERNEL STRUCTURE FOR NETWORK

Division of Computer Science & Engineering, SOE, CUSAT 22

13 PORTABILITY AND COMPILATION

Division of Computer Science & Engineering, SOE, CUSAT 23