Group A5Group A5 4th Paper Presentation 4th Paper Presentation

INFERNO Operating system INFERNO Operating system

Group Members:

Daniel Saenz

Gilbert Rahme

Sandeep George Mohan

Inferno Operating SystemsInferno Operating SystemsDeveloped in Lucent technologies by

Dennis Ritchie.Replaces a plethora of protocols in a

network by a simple unifying file service protocol (styx).

Applications compute their own name spaces and consider all resources as file systems.

Used in Embedded applns and small networked devices. Eg :CATv, PDA etc.

Interesting features of InfernoInteresting features of InfernoStyx open communication protocol.Concurrent Modular language

LIMBO.Virtual machine and byte code

interp-reter with JIT compilers.Portability and virtualization

techniques.Automatic garbage collection.

Inferno-StrengthsInferno-StrengthsPortability across processors

Runs on Intel,SPARC, AMD, MIPS etcPortability across environments

Can run as a standalone as well as a user appln in Windows NT/95, Unix, Linux, HP/UX, AIX* etc.

Distributed Design

Identical environment at client and server.

Inferno- Strengths(cont)Inferno- Strengths(cont)Minimal hardware requirements Can run useful applns as a stand alone

with as little as 1 MB of memory.Portable Applns Inferno applns are written in type-safe

LIMBO whose binary representation is identical for all platforms.

Dynamic adaptability Depending on the H/W or resource

availability,applns may use diff modules to perform a specific function.

Inferno InterfacesInferno InterfacesThe role of Inferno system is to create se-

veral standard interfaces for its applns. Applns use various resources which

include a virtual machine that runs applns programs together with library modules like string manip etc.

Applns exist in an external env containing resources such as data files and objects. Devices present themselves to the appln as files.

External env of Inferno applnsExternal env of Inferno applns The purpose of most Inferno applns is to present informn/media to user. To the applns the user’s devices shows up

as resources for it. The way the resources are designed to

show up to the applns are 1.Resources - Named & accessed like files. 2.Disjoint resource hierarchies provided by different services show up in a single hierarchical name space. 3.Regardless of whether resources are

local/global, a communication protocol called styx is used.

External env of Inferno applnsExternal env of Inferno applnsThe glue that connects diff parts of

the resource name space together is the styx protocol.

Inferno kernel implements a mount driver which transforms file operations to RPC’s for transport over the network.

On the other side of the conxn, a server unwraps the styx messages and implements them using resources local to it.

Internal env of Inferno applnsInternal env of Inferno applnsInferno applns written in LIMBO

which supports most of the standard data types and also addnl ones like tuples, lists, strings etc.

A communication mechanism called channel is present which is used to connect diff LIMBO tasks.

Multi tasking supported by the LIMBO language.

Internal env of Inferno applnsInternal env of Inferno applnsLIMBO programs are built of

modules, which are self contained units having a well defined interface containing functions,abstract data types and constants.

Modules are accessed dynamically by executing a load statement naming the desired module. Then a handle for the module is returned and the module is accessed.

Internal env of Inferno applnsInternal env of Inferno applnsLimbo is fully type checked at

compile and run time.No memory protection H/W is there.All LIMBO data and program objects

are subject to a garbage collector built deeply into LIMBO run time system.

All System data objects are kept track of and freed as soon as they become idle.

Internal env of Inferno applnsInternal env of Inferno applnsLimbo programs are complied into

byte codes representing instructions for a virtual machine called DIS.

The resulting code executes at a speed approaching that of complied C.

Underlying DIS is the inferno kernel which contains the interpretor and an on the fly complier.

Environment of the Inferno systemEnvironment of the Inferno systemInferno creates a standard environment for

applns. Identical applns programs can run under any instance of this environment-even in distributed fashion and see the same resources.

Several versions of Inferno kernel, DIS/LIMBO interpreter and device driver set can be used depending on the environment within which inferno is implemented.

Environment of the Inferno systemEnvironment of the Inferno systemWhen running as the native operating

system kernel includes all the low level glue like interrupt handlers, device drivers etc.

But when running in a hosted system like Windows NT, Inferno runs as an ordinary process.

Here instead of mapping its device control functionality to real hardware, it adapts to

the resources provided by the operating system under which it runs.

Inferno Operating SystemInferno Operating System

Styx Architecture

INTRODUCTIONINTRODUCTION

The styx protocol was proposed to meet two operating systems models, plan 9 and inferno

Its objective is to present their resources as files in a hierarchical name space

Objects may represent stored data, but may also be devices, dynamic information sources, interfaces to services, and control points

INTRODUCTION (cont’d)INTRODUCTION (cont’d)

By representing a computing resource as a form of file system, difficulties of making resource available disappear

Styx exports the resources transparentlyResources published by Styx do not need to

exist as standard files on disk– The /dev/mouse file is accessed by standard file

I/O mechanisms but has no permanent existence

INTRODUCTION (cont’d)INTRODUCTION (cont’d)

Besides interactive graphics, services such as debugging, maintenance, file backup, and even access to the underlying network hardware can be made available using Styx

Styx PROTOCOLStyx PROTOCOL

Styx is analogous to Sun NFS or Microsoft CIFS but simpler to implement.

NFS and CIFS are designed for sharing regular disk files

Unlike Styx, they are clumsy at exporting dynamic device-like files such as /dev/mouse

Styx PROTOCOLStyx PROTOCOL

Provides a view of hierarchical, tree-shaped file system name space together with access information about the files

Its users don’t see the protocol itselfStyx client is an entity on one machine;

establishes communication with server on the same or another machine

Styx PROTOCOLStyx PROTOCOL

Client mechanisms may be built into the operating system or into application libraries

Server may be part of the operating system, or application code on a separate server machine

Client and server communicate by exchanging messages

Styx PROTOCOLStyx PROTOCOL

Starting communication Navigating the file system Reading and writing a file Performing file status inquiries and

changes

• Application writers request to open, read, or write files. Styx translates the requests into the necessary byte sequences

Styx PROTOCOLStyx PROTOCOL

Styx fits at the OSI Session Layer of the ISO standard classification.

Its specification is independent of most details of machine architecture

It runs over either TCP/IP or Internet link (IL).

Styx runs fine over a Unix pipe or even using shared memory.

EXAMPLEEXAMPLE

Consider the operation: open (“/usr/rob/.profile”, O_READ);

It is translated by the underlying system into a sequence of Styx messages

Attach message authenticates the user and returns an object called a FID

A clone message duplicates the root FID The new FID is then moved to the file

/usr/rob/.profile

EXAMPLEEXAMPLE

Finally, open message checks that the user has permission to read the file

Once I/O is completed, the close message will release the FID

REFERENCESREFERENCES

http://www.vitannuova.com/inferno/papers/styx.html

Lucent Technologies Inc./ Bell Labs Technical Journal

http://techupdate.cnet.com/enterprise/0-6133429-723-3897916.html

QUESTIONS ??QUESTIONS ??