Group A5 4th Paper Presentation INFERNO Operating system

Group Members: Daniel Saenz Gilbert Rahme Sandeep George Mohan

Inferno Operating Systems

 Developed

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 Inferno

 Styx

open communication protocol.  Concurrent Modular language LIMBO.  Virtual machine and byte code interpreter with JIT compilers.  Portability and virtualization techniques.  Automatic garbage collection.

InfernoInferno-Strengths
 Portability

across processors Runs on Intel,SPARC, AMD, MIPS etc  Portability 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.

InfernoInferno- 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 Interfaces
The role of Inferno system is to create several 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 applns

The purpose of most Inferno applns is to present informn/media to user.  To the applns the users 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 applns

 The

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 RPCs 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 applns

 Inferno

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 applns

 LIMBO

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 applns

 Limbo

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 applns

 Limbo

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 system

 Inferno

creates a standard environment for applns. Identical applns programs can run under any instance of this environmenteven 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 system

 When

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 System

Styx Architecture

INTRODUCTION


 

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 (contd)


 

By representing a computing resource as a form of file system, difficulties of making resource available disappear Styx exports the resources transparently Resources 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 (contd)


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


 

Provides a view of hierarchical, tree-shaped file system name space together with access information about the files Its users dont see the protocol itself Styx client is an entity on one machine; establishes communication with server on the same or another machine

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

EXAMPLE
    

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

EXAMPLE
 

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

REFERENCES
 http://www.vitannuova.com/inferno/p

apers/styx.html  Lucent Technologies Inc./ Bell Labs Technical Journal  http://techupdate.cnet.com/enterpris e/0-6133429-723-3897916.html

QUESTIONS ??