Transcript A5_paper_4

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.

Inferno-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.

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 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 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 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 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 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 (cont’d)



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 (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 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 don’t 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 ??