Plan9 Operating System

8/6/2019 Plan9 Operating System

1/41

INFERNO OPERATING SYSTEM

A SEMINAR REPORT

Submitted by:

Shubham Baranwal

in partial fulfillment for the award of the degree

of

BACHELOR OF TECHNOLOGY

In

COMPUTER SCIENCE & ENGINEERING

Kanpur Institute Of Technology

Gautam Buddh Technical University

Kanpur 208001

April 2011


2/41

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Kanpur Institute Of Technology

Gautam Buddh Technical University

Kanpur 208001

Certificate

Certified that this is bonafide record of seminar entitled

Inferno Operating System

Presented by following student

Shubham Baranwal

Of the VIth semester ,Computer Science and Engineering in the year 2011 in thepartial fulfillment of the requirements to the award of Degree of Bachelor ofTechnology in Computer Science of Engineering of Kanpur institute of Technology .

Anshika Shukla mam Shubha Jain mamSeminar Guide Head of the Department

Computer Science and Engineering, Computer Science and Engineering,KIT,KANPUR. KIT,KANPUR.

Date:


3/41

ACKNOWLEDGEMENT

It is with greatest pleasure and pride that I present this report before you. At thismoment of triumph, it would be unfair to neglect all those who helped me in thesuccessful completion of this seminar.

First of all, I would like to place myself at the feet of God Almighty for hiseverlasting 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, Shubha Jain mam for allthe help and guidance that she provided to me.

I am grateful to my seminar guide, Anshika Shukla,for her guidance and wholehearted support and very valued constructive criticism that has driven to completethe seminar successfully.

I would take this opportunity to thank my friends who were always a source ofencouragement.

i


4/41

ABSTRACT

Inferno O.S. from Bell Labs is a distributed operating system, primarily used as aresearch vehicle. It was developed as the research successor to Unix by theComputing Sciences Research Center at Bell Labs between the mid-1980s and2002. Plan 9 replaced Unix at Bell Labs as the organization's primary platform forresearch and explores several changes to the original Unix model that improve theexperience of using and programming the system, notably in distributed multi-userenvironments. One of the key features a.dopted from Unix was the use of the filesystem to access resources. Plan 9 is an operating system kernel but also acollection of accompanying software. The bulk of the software is predominantlynew, written for Plan 9 rather than ported from Unix or other systems. The windowsystem, compilers, file server, and network services are all freshly written for Plan9.Plan 9's designers were interested in goals similar to those of microkernels , butmade different architecture and design choices to achieve them. Plan 9's designgoals included:

Resources as files: all resources are represented as files within ahierarchical file system

Namespaces: the application view of the network is a single, coherentnamespace that appears as a hierarchical file system but may represent

physically separated (locally or remotely) resourcesStandard communication protocol: a standard protocol, called 9P, isused to access all resources, both local and remote

ii


5/41

Table of Contents

Chapter Title Page No.

No.

1 Introduction to Plan9 12 Introduction to Unix 2

3 Installation of Plan9 34 Configurability And Administration 55 Design Issues Of Plan9 7

5.1 Resources As Files 75.2 Namespaces 7

5.3 Standard communication protocol 86 The Command-Level View 97 Plan9 File System 11

8 The File Server 13

9 File Caching 15

10 File Permissions 16

11 Organisation Of Network In Plan9 1811.1 Kernel Network Support 1811.2 The File System Protocol 1811.3 Kernel Organization 19


6/41

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


7/41

List of figures

Sl. No. Images Page No.

1 Installation 32 Kernel Organization 21


8/41


INTRODUCTION TO INFERNOIt was developed as the research successor to Unix by the Computing SciencesResearch Center at Bell Labs between the mid-1980s and 2002. Plan 9 replacedUnix at Bell Labs as the organization's primary platform for research and exploresseveral 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 toaccess resources. Plan 9 is an operating system , system kernel but also a collectionof accompanying software. The bulk of the software is predominantly new, writtenfor 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 thoserequired for networking and the user-interface, through the file system rather thanspecialized interfaces. Plan 9 aims to provide users with a workstation-independentworking environment through the use of the 9P protocols. Plan 9 continues to beused and developed in some circles as a research operating system and by hobbyists.

1


9/41


2 INTRODUCTION TO INFERNO

Inferno (officially trademarked as INFERNO ) is a computer operating system originallydeveloped in 1969 by a group of AT&T employees at Bell Labs including KenThompson, Dennis Ritchie and Douglas McIlroy. Today's Unix systems are splitinto various branches, developed over time by AT&T as well as various commercialvendors and non-profit organizations.

As of 2007, the owner of the trademark UNIX is The Open Group, anindustry standards consortium. Only systems fully compliant with and certified tothe Single UNIX Specification qualify as "UNIX" (others are called "Unixsystem-like" or "Unix-like").

During the late 1970s and early 1980s, Unix's influence in academic circlesled to large-scale adoption of Unix (particularly of the BSD variant, originating

from the University of California, Berkeley) by commer cial startups, the mostnotable of which is Sun Microsystems. Today, in addition to certified Unix systems,Unix-like operating systems such as Linux and BSD derivatives are commonlyencountered.Sometimes, "traditional Unix" may be used to describe a Unix or anoperating system that has the characteristics of either Version 7 Unix or UNIXSystem V.

The INFERNO OPPERATING SYSTEM is also known as PLAN 9 OPERATINGSYSTEM.

2


10/41


3 INSTALLATION OF INFERNO

Figure 1. INSTALLATION


11/41

3


12/41


When a terminal is powered on, it must be told the name of a file server to bootfrom, the operating system kernel to boot, and a user name and password. Once it iscomplete, the terminal loads the Plan 9 kernel, which sets some environmentvariables 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 terminals ID. The password is converted into a 56-bit DES key andsaved as the machine key.

When a CPU or a file server boots, it reads a key, an ID, and a domain namefrom non-volatile RAM. This allows the servers to reboot without one operatorintervention.

A ter minal runs programs depending on how it uses resources (e.g., heavycomputations on a CPU server, frequent file I/O close to the file system). A call tothe command cpu starts an rc shell on a CPU server. cpu is invoked in a riowindow. 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 maychange; 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 resultis different from rlogin which moves to a distinct namespace.The result is differentfrom NFS which keeps the namespace but runs the process locally.

4


13/41


4 CONFIGURABILITY AND ADMINISTRATION

The uniform interconnection of components in Plan 9 makes it possible to configurea Plan 9 installation many different ways. A single laptop PC can function as astandard alone Plan 9 system; at the other extreme, our setup has centralmultiprocessor CPU servers and file servers and scores of terminals ranging fromsmall 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 SGIworkstation is the same as on a laptop. Since computing and file services arecentralized, and terminals have no permanent file storage, all terminals arefunctionally identical. In this way, Plan 9 has one of the good properties of oldtimesharing systems, where a user could sit in front of any machine and see thesame system. In the modern workstation community, machines tend to be owned by

people who customize them by storing private information on local disk. We rejectthis style of use, although the system itself can be use this way. In our group, wehave 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 administrationand 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 specialuses, but the system software resides on one machine. This means that each programhas a single copy of the binary for each architecture, so it is trivial to install updatesand bug fixes. There is also a single user database; there is no need to synchronizedistinct/etc/password files. On the other hand, depending on a single central serverdoes limit the size of an installation.

Another example of the power of centralized file service is the way Plan 9administers network information. On the central server there is a directory, /lib/ndb,that contains all the information necessary to administer the local Ethernet and othernetworks. All the machines use the same database to talk to the network; there is noneed to manage a distributed naming system or keep parallel files up to date. Toinstall a new machine on the local Ethernet and other networks. All the machines

5


14/41


use the same database to talk to the network; there is no need to manage adistributed naming system or keep parallel files up to date. To install a new machineon the local Ethernet, choose a name and IP address and add these to a single filein /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 andTFTP to load the kernel. All else is automatic.

Finally, the automated dump file system frees all users from the need tomaintain their systems, while providing easy access to backup files without tapes,special commands, or the involvement of support staff. It is difficult to overstate theimprovement in lifestyle afforded by this service.

Plan 9 runs on a variety of hardware without constraining how to configurean installation. In our laboratory, we chose to use central servers because theyamortize costs and administration. A sign that this is a good decision is that ourcheap terminals remain comfortable places to work for about five years, muchlonger than workstations that must provide the complete computing environment.We do, however, upgrade the central machines, so the computation available fromeven old Plan 9 terminals improves with time.

6


15/41


5 DESIGN ISSUES OF INFERNO

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'sdesign 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", thatis, a unique path to any object whether it be a file, screen, user, or computer. Allwere handled using the existing Unix standards, but extended such that anyobject could be named and addressed (similar in concept to the more widelyknown UR I system of the world wide web). In Unix, devices such as printershad been represented by names using software converters in /dev, but theseaddressed only devices attached by hardware, and did not address networkeddevices. Under Plan 9 printers were as virtualized as files, and both could beaccessed over the network from any workstation.Another Plan 9 innovation wasthe 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 privilegesby 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, coherentnamespace that appears as a hierarchical file system but may represent

physically separated (locally or remotely) resources.N amespace is an abstractcontainer providing context for the items (names, or technical terms, or words) itholds and allows disambiguation of items having the same name (residing indifferent namespaces).As a rule, names in a namespace cannot have more thanone meaning, that is, two or more things cannot share the same name. Anamespace is also called a context, as the valid meaning of a name can changedepending on what namespace applies. Names in it can represent objects as wellas concept, whether it is a natural or ethnic language, a constructed language,the technical terminology of a profession, a dialect, a sociolect, or an artificiallanguage (e.g., a programming language)

7


16/41


For many programming languages, a namespace is a context for identifiers.In an operating system, an example of namespace is a directory. It contains itemswhich must have unique names. In the Java programming language, items thatappear in namespaces have a short (local) name and unique long "qualified" namesfor use outside the name space. Also, some languages (such as C) combinenamespace and names in a process called name mangling in order to eradicateambiguity.

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 oftransactions that send a request from a client to a (local or remote) server and returnthe result. 9P controls file systems, not just files: it includes procedures to resolvefile 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 onor with the server, a distinction from systems such as Sprite [OCDNW88]. Also, fileaccess 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 filesystem structures [Welc94].9P (or the Plan 9 Filesystem Protocol or Styx ), is a network protocol developed forthe 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 representwindows, network connections, processes, and almost anything else available in theoperating 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 Plan9 under the name 9P2000 that contained various fundamental improvements. Thelatest version of Inferno also uses 9P2000. The Inferno file protocol was originallycalled Styx, but technically it has always been a variant of 9P.

There is a server implementation of 9P for Unix called u9fs included in thePlan 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 asthe Styx on a Brick project.

8


17/41


6 THE COMMAND-LEVEL VIEW

Plan 9 is meant to be used from a machine with a screen running the window systemIt has no notion of _teletype_ in the UNIX sense. The keyboard handling of the baresystem is rudimentary, but once the window system, 8 [Pike91], is running, textcan 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 currentinput line. The text-editing capabilities of 8 are strong enough to displace specialfeatures such as history in the shell, paging and scrolling, and mail editors. 8windows do not support cursor addressing and, except for one ter minal emulator tosimplify connecting to traditional systems, there is no cursor-addressing software inPlan 9.

Each window is created in a separate name space. Adjustments made to thenamespace in a window do not affect other windows or programs, making it safe toexperiment with local modifications to the name space, for example to substitutefiles from the dump file system when debugging. Once the debugging is done, thewindow can be deleted and all trace of the experimental apparatus is gone. Similararguments 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. Eachwindow 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 isimplemented as a file server. Unlike X windows, where a new application typicallycreates a new window to run in, an 8 graphics application usually runs in thewindow where it starts. It is possible and efficient for an application to create a newwindow, but that is not the style of the system. Again contrasting to X, in which aremote 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 notknow whether the files are local. It just reads and writes them to control thewindow; the network connection is already there and multiplexed.

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

9


18/41


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, simplerimplementations. Who, for example, is a shell script, while ps is just 95 lines of Ccode. 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 arestill 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 toolswith similar jobs. Finally, about half the commands are new.

10


19/41


20/41


daily snapshots of all files, it is easy to find when a particular change was made orwhat changes were made on a particular date. People feel free to make largespeculative changes to files in the knowledge that they can be backed out with asingle copy command. There is no backup system as such; instead, because thedump is in the file name space, backup problems can be solved with standard toolssuch 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 cacheand 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 madeafter the date of the dump, this recovery method results in a very slow system. Thecache 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 anyspecial arrangement. The dump file system is read-only, though, which means thatfiles 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 bechanged.

Once a file is written to WORM, it cannot be removed, so our users neversee ``please clean up your files'' messages and there is no df command. We regardthe WORM jukebox as an unlimited resource. The only issue is how long it willtake to fill.

12


21/41


8 THE FILE SERVER

A central file server stores permanent files and presents them to the network as a filehierarchy 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 afixed set of routines compiled into the boot image. Rather than a set of disks orseparate 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 awide area on a variety of networks. Other file trees exported by the server includespecial-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 magneticdisks, 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 thelevel it caches. The addressable data in the file system can be larger than the size ofthe magnetic disks, because they are only a cache; our main file server has about 40gigabytes of active storage.

The most unusual feature of the file server comes from its use of a WORMdevice for stable storage. Every morning at 5 oclock, a dump of the file systemoccurs automatically. The file system is frozen and all blocks modified since the lastdump are queued to be written to the WORM. Once the blocks are queued, serviceis restored and the read-only root of the dumped file system appears in a hierarchyof 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 appearedin 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, maytake hours.

The most unusual feature of the file server comes from its use of a WORMdevice for stable storage. Every morning at 5 oclock, a dump of the file systemoccurs automatically. The file system is frozen and all blocks modified since the lastdump are queued to be written to the WORM. Once the blocks are queued, service

13


22/41


is restored and the read-only root of the dumped file system appears in a hierarchy ofall 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 appearedin 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, maytake hours.

There are two ways the dump file system is used. The first is by the usersthemselves, who can browse the dump file system directly or attach pieces of it totheir namespace. For example, to track down a bug, it is straightforward to try thecompiler from three months ago or to link a program with yesterdays library. Withdaily snapshots of all files, it is easy to find when a particular change was made orwhat changes were made on a particular date. People feel free to make largespeculative changes to files in the knowledge that they can be backed out with asingle copy command. There is no backup system as such; instead, because thedump is in the file name space, backup problems can be solved with standard toolssuch 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 cacheand 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 madeafter the date of the dump, this recovery method results in a very slow system. Thecache 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..

14


23/41


9 FILE CACHING

The 9P protocol has no explicit support for caching files on a client. The largememory of the central file server acts as a shared cache for all its clients, whichreduces 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 slowconnection 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 importantis client caching of text and data segments of executable files. When a process execsa program, the file is re-opened and the qids version is compared with that in thecache; if they match, the local copy is used. The same method can be used to build alocal caching file server. This user-level server interposes on the 9P connection tothe remote server and monitors the traffic, copying data to a local disk. When it seesa read of known data, it answers directly, while writes are passedon immediately_the cache is write-through_to keep the central copy up to date. This istransparent to processes on the terminal and requires no change to 9P; it works wellon 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 inPlan 9.

15


24/41


10 FILE PERMISSIONSOne of the advantages of constructing services as file systems is that the solutions toownership and permission problems fall out naturally. As in UNIX, each fileordirectory has separate read, write, and execute/search permissions for the fileowner, the files 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 thegroup. Conventions make the distinction: most people have user names withoutgroup members, while groups have long lists of attached names. For example, thesys group traditionally has all the system programmers, and system files areaccessible by group sys. Consider the following two lines of a user database storedon a server:

PJW:PJW:SYS::PJW,KEN,PHILW,PRESOTTO

The first establishes userpjw as a regular user. The second establishes user sys as agroup 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 aleader, that user has special permissions for the group, such as freedom to changethe group permissions of files in that group. If no leader is specified, each memberof 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 systems members are equal partnersin that group. Regular files are owned by the user that creates them. The group nameis inherited from the directory holding the new file. Device files are treatedspecially: the kernel may arrange the ownership and permissions of a fileappropriate to the user accessing the file.

A good example of the generality this offers is process files which are ownedand read-protected by the owner of the process. If the owner wants to let someoneelse access the memor y of a process, for example to let the author of a programdebug 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 protectionas files in the regular file system; if a file is owned by pjw and read-protected, onceit is in the dump file system it is still owned by pjw and read-protected. Also, since

16


25/41


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

17


26/41


11 ORGANISATION OF NETWORK IN PLAN911.1 Kernel Network Support

Networks play a central role in any distributed system. This is particularly true inPlan 9 where most resources are provided by servers external to the kernel. Theimportance of the networking code within the kernel is reflected by its size; of25,000 lines of kernel code, 12,500 are network and protocol related. Networks arecontinually being added and the fraction of code devoted to communications is

growing. Moreover, the network code is complex. Protocol implementations consistalmost entirely of synchronization and dynamic memory management, areasdemanding subtle error recovery strategies. The kernel currently supports Datakit,

point-to-point fiber links, an Internet (IP) protocol suite and ISDN data service. Thevariety of networks and machines has raised issues not addressed by other systemsrunning 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 filesystem. Each process assembles a view of the system by building a name space[Needham] connecting its resources. File systems need not represent disc files; infact, 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 orremote file servers uses a protocol called 9P. The protocol consists of 17 messagesdescribing operations on files and directories. Kernel resident device and protocoldrivers use a procedural version of the protocol while external file servers use anRPC form. Nearly all traffic between Plan 9 systems consists of 9P messages. 9Prelies on several properties of the underlying transport protocol. It assumes messagesarrive 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 handingthem to the system transport protocol. It assumes messages arrive reliably and insequence and that delimiters between messages are preserved. When a protocol doesnot meet these requirements (for example, TCP does not preserve delimiters) we

provide mechanisms to marshal messages before handing them to the system.

18


27/41


A kernel data structure, the channel, is a handle to a file server. Operations ona channel generate the following 9P messages. The session and attach messagesauthenticate 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 clonemessage makes a new channel identical to an existing channel, much like the dupsystem call. A channel may be moved to a file on the server using a walk message todescend each level in the hierarchy. The stat and wstat messages read and write theattributes of the file referenced by a channel. The open message prepares a channelfor subsequent read and write messages to access the contents of the file. Create andremove perform the actions implied by their names on the file referenced by thechannel. The clunk message discards a channel without affecting the file.A kernelresident file server called the mount driver converts the procedural version of 9Pinto RPCs. The mount system call provides a file descriptor, which can be a pipe toa user process or a network connection to a remote machine, to be associated withthe mount point. After a mount, operations on the file tree below the mount pointare sent as messages to the file server. The mount driver manages buffers, packs andunpacks parameters from messages, and demultiplexes among processes using thefile server

11.3 Kernel Organization

The network code in the kernel is divided into three layers: hardwareinterface, protocol processing, and program interface. A device driver typically usesstreams 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 filesystem. Simple device drivers serve a single level directory containing just a fewfiles; for example, we represent each UART by a data and a control file.

cpu% cd /devcpu% 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

19


28/41


--rw-rw-rw- t 0 bootes bootes 0 Jul 16 17:28 eia2ctlcpu%The control file is used to control the device; writing the string b1200 to /dev/eia1ctlsets the line to 1200 baud.Multiplexed devices present a more complex interface structure. For example, theLANCE 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 canuse this value to construct the name of the proper connection directory. In eachconnection directory files named ctl, data, stats, and type provide access to theconnection. Writing the string connect 2048 to the ctl file sets the packet type to2048 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 queuesa packet for transmission after appending a packet header containing the sourceaddress and packet type. The stats file returns ASCII text containing the interfaceaddress, packet input/output counts, error statistics, and general infor mation aboutthe state of the interface.

20


29/41


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 specialpacket type -1 selects all packets. Writing the strings promiscuous and connect -1to the ctl file configures a conversation to receive all packets on the Ethernet.

21


30/41


12 KERNEL STRUCTURE FOR NETWORKThe kernel plumbing used to build Plan 9 communications channels is calledstreams [R it84][Presotto]. A stream is a bidirectional channel connecting a physicalor pseudo- device to a user process. The user process inserts and removes data at oneend of the stream; a kernel process acting on behalf of a device operates at the otherend. A stream comprises a linear list of processing modules. Each module has bothan 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 thestream.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.

.

22


31/41


13 PORTABILITY AND COMPILATION

Plan 9 is portable across a variety of processor architectures. Within a single computing session, it is common to use several architectures: perhaps the windowsystem running on an Intel processor connected to a MIPS-based CPU server withfiles resident on a SPARC system. For this heterogeneity to be transparent, theremust 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 astext whenever practical. Sometimes, though, the amount of data is high enough thata 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 complexenough to be defined by a data structure, the structure is never communicated as aunit instead, it is decomposed into individual fields, encoded as an ordered bytestream, and then reassembled by the recipient. These conventions affect dataranging from kernel or application program state information to object fileintermediates generated by the compiler.

Programs, including the kernel, often present their data through a file systeminterface, an access mechanism that is inherently portable. For example, the systemclock is represented by a decimal number in the file /dev/time; the time libraryfunction (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 flagsand bits in private memory, the kernel presents a text string in the file named statusin the /proc file system associated with each process. The Plan 9 ps command istrivial: 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 ofHelixs processes.

Each supported architecture has its own compilers and loader. The C and Alefcompilers produce intermediate files that are portably encoded; the contents areunique to the target architecture but the format of the file is independent ofcompiling processor type. When a compiler for a given architecture is compiled onanother type of processor and then used to compile a

23


32/41


program there, the intermediate produced on the new architecture is identical to theintermediate 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 architectur e, such files could have been generated by acompiler executing on any type of processor. For instance, it is possible to run theMIPS compiler on a 486, then use the MIPS loader on a SPARC to produce a MIPSexecutable.

24


33/41


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 forsynchronization 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 isa feasible approach in Plan 9 because the kernel has an efficient system callinterface 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 parentprocess_s resources should be shared, copied, or created anew in the child. Theresources controlled by rfork include the name space, the environment, the filedescriptor 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 isoff, 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 fromits parents. Alef uses a fine-grained fork in which all the resources, includingmemory, are shared between parent and child, analogous to creating a kernel threadin many systems Anindication that rfork is the right model is the variety of ways it is used. Other thanthe canonical use in the library routine fork, it is hard to find two calls to rfork withthe same bits set; programs use it to create many different forms of sharing andresource allocation. A system with just two types of processes_regular processesand threads_could not handle this variety .

25


34/41


15 HARDWARE REQUIREMENTS

IDE/ATAPI CONTROLLERS

Plan 9 supports almost all motherboard IDE/ATAPI controllers, but DMA transfersare only used on these recognized chipsets (chipsets not listed here will simply runslower; 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 B T-958 (AKA Mylex multimaster series). These aren't beingmade any more, but you might be able to buy them used.Adaptec 1540 or 1542 for the ISA busUltrastor 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 aUSB 2 device (e.g., disk) into a system containing an EHCI controller causes allUSB traffic to be routed to the EHCI controller, despite the presence of UHCI orOHCI controllers

26


35/41


ETHERNET

Plan 9 will automatically recognize the PCI Ethernet cards that it can drive. Thefollowing 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

27


36/41


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

28


37/41


16 FEATURES OF INFERNO

Plan 9 is designed around the basic principle that all resources appear as files in ahierarchical file system (namespace) which is unique to each process . Theseresources are accessed via a network-level protocol called 9P which hides the exactlocation of services from the user. All servers provide their services as an exported

hierarchy of filesFeatures-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 thenetwork-Venti - archival storage-Fossil - Hierarchical file system built on top of Venti, with automatic snapshots andarchives

29


38/41


17 PERFORMANCEAs a simple measure of the performance of the Plan 9 kernel, we compared the timeto do some simple operations on Plan 9 and on SGI_s IRIX Release 5.3 running onan SGI Challenge M with a 100MHz MIPS R4400 and a 1-megabyte secondarycache. The test program was written in Alef, compiled with the same compiler, andrun 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 Plan9,blockproc on IRIX); a trivial system call (rfork(0) and nap(0)); andlightweightfork (rfork(RFPROC) and sproc(PR_SFDS|PR_SADDR)). It alsomeasures the time to send a byte on a pipe from one process to another and thethroughput on a pipe

TEST PLAN9 IRIX

CONTEX SWITCH 39 150 s s

SYSTEM CALL 36 6 s s

LIGHT FORK 1300 2200 s s

PIPE LATENCY 1100 200 s s

PIPE BANDWIDTH 11678 14545 KB/s KB/s

Performance comparison .

30


39/41


18 APPLICATIONS OF INFERNO18.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 smalldevice (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 werealso re-emerging with Java language technology18.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: thebrick.

18.3 Viaduct-A small box (15 cm long) provides VPN (Virtual Private Network) securetunneling 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

31


40/41


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 thenew and interesting places in which to work

32


41/41


20 REFERENCES

Inferno Programmer's Manual, Volume 1

,

T.J. Killian, Processes as FilesB. Clifford Neuman, The Prospero File Systemhttp://en.wikipedia.org/wiki/Comparison_of_operating_systems

33

Date post:	07-Apr-2018
Category:	Documents
Upload:	vivekkit
View:	222 times
Download:	0 times

Plan9 Operating System

Documents