Beruflich Dokumente
Kultur Dokumente
On
Inferno Os
submitted by
KISHOR KUNAL
Bachelor of Technology(B.Tech)
In
Computer Science & Engineering
AUGUST 2010
ACKNOWLEDGEMENT
I also extend my sincere thanks to all other members of the faculty of Computer
Science and Engineering Department and my friends for their
co-operation and encouragement.
KISHOR KUNAL
i
ABSTRACT
Inferno is an operating system for creating and supporting distributed services .The
name of the operating system and of its associated programs, as well as of the company
Vita Nuova Holding that produces it, were inspired by the litrary works of Dante
Alighieri, particularly the Divine Comedy. Inferno runs in hosted mode under several
configuration the operating system presents the same standard interfaces to its
local and remote resources. Applications are written in the type-safe Limbo
ii
CONTENTS
ACKNOWLEDGEMENT I
ABSTRACT II
CONTENTS III
CHAPTER 1 INTRODUCTION 5
CHAPTER 11 CONCLUSION 34
REFERENCES 35
iii
Inferno Os
CHAPTER 1
INTRODUCTION
Inferno is intended to be used in a variety of network environments, for example
cable or satellite systems, and inexpensive Internet computers, but also in conjunction
The most visible new environments involve cable television, direct satellite
and computing industries converge and interconnect, a variety of public data networks are
emerging, each potentially as useful and profitable as the telephone system. Unlike the
telephone system, which started with standard terminals and signaling, these networks are
developing in a world of diverse terminals, network hardware, and protocols. Only a well-
designed, economical operating system can insulate the various providers of content and
services from the equally varied transport and presentation platforms. Inferno is a network
Inferno's definitive strength lies in its portability and versatility across several dimensions:
Portability across processors: it currently runs on Intel, Sparc, MIPS, ARM, HP-PA,
terminals, and also as a user application under Windows NT, Windows 95, Unix (Irix,
Solaris, FreeBSD, Linux, AIX, HP/UX) and Plan 9. In all of these environments, Inferno
and at the server, and each may import the resources (for example, the attached I/O
devices or networks) of the other. Aided by the communications facilities of the run-time
system, applications may be split easily (and even dynamically) between client and server.
hardware.
resources available, load different program modules to perform a specific function. For
example, a video player application might use any of several different decoder modules.
intends to stimulate. Many providers are interested in purveying media and services:
telephone network service providers, WWW servers, cable companies, merchants, various
modems, ISDN, ATM, the Internet, analog broadcast or cable TV, cable modems, digital
Applications more clearly related to Lucent's current and planned product offerings
include control of switches and routers, and the associated operations system facilities
Division Of Computer Engineering, SOE Page 6
Inferno Os
needed to support them. For example, Inferno software controls an IP switch/router for
voice and data being developed by Lucent's Bell Labs research and Network Systems
Finally, there are existing or potential hardware endpoints. Some are in consumers'
homes: PCs, game consoles, newer set-top boxes. Some are inside the networks
themselves: nodes for billing, network monitoring or provisioning. The higher ends of
fascinating, but have developed more slowly than expected. One reason is the cost of the
set-top box, especially its memory requirements. Portable terminals, because of weight
applications on today's hardware, while being versatile enough to grow into the future. In
particular, it enables developers to create applications that will work across a range of
facilities. An example: an interactive shopping catalog that works in text mode over a
POTS modem, shows still pictures (perhaps with audio) of the merchandise over ISDN,
Clearly not everyone who deploys an Inferno-based solution will want to span the
whole range of possibilities, but the system architecture should be constrained only by the
desired markets and the available interconnection and server technologies, not by the
software.
CHAPTER 2
DESIGN PRINCIPLES
file system
that appears as a hierarchical file system but may represent physically separated (locally or
remotely) resources
Resources as Files :
All Inferno resources, both local and remote, are represented as a set of dynamic
files within the hierarchical file system. These files are used to represent, among other
application may access each resource by manipulating the relevant files as required using
standard file operations. The advantages if using files as a central concept in the system
are:
File systems have simple and well understood interfaces across a wide variety of
operating systems. Interfaces to the files generally consist of a small set of well-defined
Reliance on file systems reduces the amount of interface code and keeps the Inferno
Naming conventions for files are well known, uniform and easily understood
Access rights and permissions to files are simple, yet can be used to ensure multiple
levels of security
File names and contents of these dynamic files can be generated on a per-demand
and per-client basis. For instance a data file for a sensor resource might return different
output depending on the time of the read, or for each read a new line of data might be
returned.
Namespaces
application builds a unique private view of the resources and services it needs to access.
Each set of resources is represented as a hierarchy of files and is accessible via the
standard file access operations. The various resources and services being used by a
process are combined into a single rooted hierarchy of file names, called a namespace. The
One of the main advantages of this namespace system is that an application may use
resources completely transparently. Once the dynamic files present by the resource are
mounted within the namespace visible to application, it may access them without knowing
For example, the graphical debugger reads the dynamic files in the directory to
access information about the current system processes. If however, the user wished to
debug a process on a remote machine, all that would be required is to import the directory
from that machine. As far as the debugger is concerned, it is just reading the files in as
The third key principle of Inferno is the use of a standard communications protocol
called Styx. As all resources, including networks and network connections, are
represented as files, only one protocol is required to communicate with and provide access
to resources, both local and remote. This approach provides a natural way to build
distributed systems by using well known technology for attaching remote file systems.
Having one standard communication protocol also provides a single point on which to
Message encryption
As this is part of the underlying system, all applications gain these benefits automatically.
Styx runs over various transport protocols including TCP/IP, ATM and PPP.
CHAPTER 3
INFERNO INTERFACES
The role of the Inferno system is to create several standard interfaces for its applications:
virtual machine that runs the application programs, together with library modules that
services for dealing with text, pictures, higher-level toolkits, and video.
files that can be read and manipulated, together with objects that are named and
manipulated like files but are more active. Devices (for example a hand-held remote
files.
Standard protocols exist for communication within and between separate machines
terminals running Inferno as a native system, and a smaller number of large machines
running Inferno as a hosted system. On these server machines Inferno might interface to
databases, transaction systems, existing OA&M facilities, and other resources provided
under the native operating system. The Inferno applications themselves would run either
Inferno architecture
Inferno has mainly three layers. They are application layer, kernel layer and
hardware layer. Application layer include Limbo applications and VM.Kernel layer
library. Hardware layer include host os, device drivers and network interface
CHAPTER 4
APPLICATION LAYER
Limbo programs are built of modules, which are self-contained units with a well-
defined interface containing functions (methods), abstract data types, and constants
defined by the module and visible outside it. Modules are accessed dynamically; that is,
when one module wishes to make use of another, it dynamically executes a load statement
naming the desired module, and uses a returned handle to access the new module. When
the module is no longer in use, its storage and code will be released. The flexibility of the
modular structure contributes to the smallness of typical Inferno applications, and also to
their adaptability. For example, in the shopping catalog described above, the application's
main module checks dynamically for the existence of the video resource. If it is
besides being more restricted than in C, are checked before being dereference, and the
Limbo data and program objects are subject to a garbage collector, built deeply into the
Limbo run-time system. All system data objects are tracked by the virtual machine and
freed as soon as they become unused. For example, if an application task creates a
graphics window and then terminates, the window automatically disappears the instant the
DisVirtualmachine
virtual machine called Dis. The architecture of the arithmetic part of Dis is a simple 3-
address machine, supplemented with a few specialized operations for handling some of the
higher-level data types like arrays and strings. Garbage collection is handled below the
level of the machine language; the scheduling of tasks is similarly hidden. When loaded
into memory for execution, the byte-codes are expanded into a format more efficient for
execution; there is also an optional on-the-fly compiler that turns a Dis instruction stream
into native machine instructions for the appropriate real hardware. This can be done
efficiently because Dis instructions match well with the instruction-set architecture of
today's machines. The resulting code executes at a speed approaching that of compiled C.
Underlying Dis is the Inferno kernel, which contains the interpreter and on-the-fly
compiler as well as memory management, scheduling, device drivers, protocol stacks, and
the like. The kernel also contains the core of the file system (the name evaluator and the
code that turns file system operations into remote procedure calls over communications
internally. These include Sys, which provides system calls and a small library of useful
basic graphics library that handles raster graphics, fonts, and windows. Module Prefab
builds on Draw to provide structured complexes containing images and text inside of
windows; these elements may be scrolled, selected, and changed by the methods of
CHAPTER 5
KERNEL LAYER
Namespace :
Each set of resources is represented as a hierarchy of files and is accessible via the
standard file access operations. The various resources and services being used by a
process are combined into a single rooted hierarchy of file names, called a namespace. The
One of the main advantages of this namespace system is that an application may
use resources completely transparently. Once the dynamic files present by the resource are
mounted within the namespace visible to application, it may access them without knowing
For example, the graphical debugger reads the dynamic files in the directory to
access information about the current system processes. If however, the user wished to
debug a process on a remote machine, all that would be required is to import the directory
from that machine. As far as the debugger is concerned, it is just reading the files in as
Memory management
responsible for managing all system memory which is currently in use by programs. This
ensures that a program does not interfere with memory already used by another program.
Since programs time share, each program must have independent access to memory.
that all programs make voluntary use of the kernel's memory manager, and do not exceed
their allocated memory. This system of memory management is almost never seen
anymore, since programs often contain bugs which can cause them to exceed their
allocated memory. If a program fails it may cause memory used by one or more other
alter another program's memory or may affect the operation of the operating system itself.
With cooperative memory management it takes only one misbehaved program to crash the
system.
Memory protection enables the kernel to limit a process' access to the computer's
and paging. All methods require some level of hardware support (such as the 80286
Process management
Process management is an integral part of any modern day operating system (OS).
The OS must allocate resources to processes, enable processes to share and exchange
information, protect the resources of each process from other processes and enable
data structure for each process, which describes the state and resource ownership of that
process, and which enables the OS to exert control over each process.
Security in Inferno
Once communication is set up, the encryption is transparent to the application. Key
message digesting and line encryption likewise use standard symmetric mechanisms.
collaboration between mutually suspicious service providers and clients. The resources
available to applications appear exclusively in the name space of the application, and
standard protection modes are available. This applies to data, to communication resources,
and to the executable modules that constitute the applications. Security-sensitive resources
of the system are accessible only by calling the modules that provide them; in particular,
adding new files and servers to the name space is controlled and is an authenticated
operation. For example, if the network resources are removed from an application's name
Object modules may be signed by trusted authorities who guarantee their validity
and behavior, and these signatures may be checked by the system the modules are
accessed.
as detailed below, few application programs need to be aware of them or explicitly include
coding to make use of them. Most often, access to resources across a secure
communications link is arranged in advance by the larger system in which the application
operates. For example, when a client system uses a server system and connection
authentication or link encryption is appropriate, the server resources will most naturally be
supplied as a part of the application's name space. The communications channel that
carries the Styx protocol can be set to authenticate or encrypt; thereafter, all use of the
Security mechanisms
Authentication and digital signatures are performed using public key cryptography. Public
keys are certified by Inferno-based or other certifying authorities that sign the public keys
The encryption algorithms provided by Inferno include the SHA, MD4, and MD5
secure hashes; Elgamal public key signatures and signature verification [4]; RC4
encryption; DES encryption; and public key exchange based on the Diffie-Hellman
scheme. The public key signatures use keys with module up to 4096 bits, 512 bits by
default.
generating public or private encryption keys. Thus Inferno includes tools for using or
implementing a trusted authority, but it does not itself provide the authority, which is an
administrative function. Thus an organization using Inferno (or any other security and
key-distribution scheme) must design its system to suit its own needs, and in particular
decide whom to trust as a Certifying Authority (CA). However, the Inferno design is
practice.
The certifying authority that signs a user's public key determines the size of the key
and the public key algorithm used. Tools provided with Inferno use these signatures for
authentication. Library interfaces are provided for Limbo programs to sign and verify
signatures.
by having their public keys signed by the certifying authority (CA). The signature covers a
secure hash (SHA, MD4, or MD5) of the name of the party, his public key, and an
expiration time. The signature, which contains the name of the signer, along with the
When parties communicate, they use the Station to Station protocol[5] to establish the
identities of the two parties and to create a mutually known secret. This STS protocol uses
the Diffie-Hellman algorithm [6] to create this shared secret. The protocol is protected
against replay attacks by choosing new random parameters for each conversation. It is
secured against `man in the middle' attacks by having the parties exchange certificates and
then digitally signing key parts of the protocol. To masquerade as another party an
Line Security
modification and snooping. To secure against modification, Inferno can append a secure
to each message. Message is a 32 bit number that starts at 0 and is incremented by one for
each message sent. Thus messages can be neither changed, removed, reordered or inserted
into the stream without knowing the secret or breaking the secure hash algorithm.
conversation using either RC4 or DES with either DES chain block coding (DESCBC)
Inferno uses the same encapsulation format as Netscape's Secure Sockets Layer It is
degrees of security.
Random Numbers
numbers used for choosing keys, Diffie-Hellman parameters, initialization vectors, etc.
Inferno achieves this in two steps: a slow (100 to 200 bit per second) random bit stream
comes from sampling the low order bits of a free running counter whenever a clock ticks.
The clock must be unsynchronized, or at least poorly synchronized, with the counter. This
generator is then used to alter the state of a faster pseudo-random number generator. Both
the slow and fast generators were tested on a number of architectures using self
Communications
The second value in the tuple returned from wmlib->titlebar is a built-in Limbo
the manner of Hoare's CSP[15]. Two processes that wish to communicate do so using a
shared channel; data sent on the channel by one process may be received by another
communicate before the data changes hands, and if one is not ready the other blocks until
it is. Channels are a feature of the Limbo language: they have a declared type ( chan of
int, chan of list of string, etc.) and only data of the correct type may be sent. There is
no restriction on what may be sent; one may even send a channel on a channel. Channels
The threading and communications primitives in Limbo are not designed to implement
efficient multicomputer algorithms, but rather to provide an elegant way to build active
CHAPTER 6
HARDWARE LAYER
Device drivers
and the applications or operating systems that use it. The higher-level code can be written
device, such as a printer, requires its own specialized commands. In contrast, most
generic commands, such as PRINTLN. The driver accepts these generic statements and
A driver typically communicates with the device through the computer bus or
invokes a routine in the driver, the driver issues commands to the device. Once the device
sends data back to the driver, the driver may invoke routines in the original calling
provide the interrupt handling required for any necessary asynchronous time-dependent
Host os
Host systems
Windows NT/2000/XP
Linux
MacOS
Plan9os
CHAPTER 7
INFERNO RESOURCES
An inferno device implements a file tree for client processes. A file name begin
with a hash symbol ,such as #c, names the root of a file tree implemented by a particular
kernel device driver identified by the character after the hash. Such names are usually
bound to conventional locations in the namespace. ls will list the files provided by the
console device.
Resources represent local and remote files and even devices, with access rights and
attributes.
user; thus applications must locate the information sources in the network and construct a
local representation of them. The information flow is not one-way: the user's terminal
source and its devices represent resources to applications. Inferno draws heavily on the
design of the Plan 9 operating system in the way it presents resources to these
applications.
In practice, most applications see a fixed set of files organized as a directory tree.
Some of the files contain ordinary data, but others represent more active resources.
Devices are represented as files, and device drivers (such as a modem, an MPEG decoder,
themselves as small directories. These directories typically containing two files, data and
ctl, which respectively perform actual device input/output and control operations. System
services also live behind file names. For example, an Internet domain name server might
be attached to an agreed-upon name (say /net/dns); after writing to this file a string
representing a symbolic Internet domain name, a subsequent read from the file would
The glue that connects the separate parts of the resource name space together is the
Styx protocol. Within an instance of Inferno, all the device drivers and other internal
resources respond to the procedural version of Styx. The Inferno kernel implements a
mount driver that transforms file system operations into remote procedure calls for
transport over a network. On the other side of the connection, a server unwraps the Styx
messages and implements them using resources local to it. Thus, it is possible to import
parts of the name space (and thus resources) from other machines.
To extend the example above, it is unlikely that a set-top box would store the code
needed for an Internet domain name-server within itself. Instead, an Internet browser
would import the /net/dns resource into its own name space from a server machine across
a network.
The Styx protocol lies above and is independent of the communications transport
layer; it is readily carried over TCP/IP, PPP, ATM or various modem transport protocols.
Inferno applications are written in a new language called Limbo, which was
designed specifically for the Inferno environment. Its syntax is influenced by C and
Pascal, and it supports the standard data types common to them, together with several
higher-level data types such as lists, tuples, strings, dynamic arrays, and simple abstract
data types.
used to connect different Limbo tasks on the same machine or across the network. A
attached to files in the name space for language-level communication between machines.
scheduled threads of control may be spawned, and an alt statement is used to coordinate
the channel communication between tasks (that is, alt is used to select one of several
channels that are ready to communicate). By building channels and tasks into the language
and its virtual machine, Inferno encourages a communication style that is easy to use and
safe.
Limbo is the application programming language for the Inferno operating system.
Although Limbo looks syntactically like C, it has a number of features that make it easier
to use, safer, and more suited to the heterogeneous, networked Inferno environment: a rich
set of basic types, strong typing, garbage collection, concurrency, communications, and
modules. Limbo may be interpreted or compiled `just in time' for efficient, portable
execution.
concurrency, graphics, module loading, and other features of Limbo and Inferno
programs can run under any instance of this environment, even in distributed fashion, and
see the same resources. Depending on the environment in which Inferno itself is
implemented, there are several versions of the Inferno kernel, Dis/Limbo interpreter, and
When running as the native operating system, the kernel includes all the low-level
glue (interrupt handlers, graphics and other device drivers) needed to implement the
abstractions presented to applications. For a hosted system, for example under Unix,
provided by the operating system under which it runs. For example, under Unix, the
graphics library might be implemented using the X window system and the networking
using the socket interface; under Windows, it uses the native Windows graphics and
Winsock calls.
Inferno is, to the extent possible, written in standard C and most of its components
are independent of the many operating systems that can host it.
CHAPTER 8
ADVANTAGES OF INFERNO
Inferno applications can run in different platforms since the applications are written
in the limbo language and the binary representation of limbo is same in all machines.
With inferno resources can be imported and exported over a network. These
resources may then be used without the user knowing, or needing to know, if the
Secure communication
Inferno provides strong peer-to-peer public key encryption and authentication. The use
of single communication means that security can be focused on just one point and don’t
may also be encrypted using a variety of secure algorithms to ensure that data is kept
CHAPTER 9
DISADVANTAGES OF INFERNO
New version of the Inferno, displays graphical image files on the screen, one per
window. This version sacrifices some functionality, generality, and error-checking but
performs the basic job. The files may be in either GIFor JPEG format and must be
converted before display, or they may already be in the Inferno standard format that needs
no conversion. View `sniffs' each file to determine what processing it requires, maps the
colors if necessary, creates a new window, and copies the converted image to it. Each
window is given a title bar across the top to identify it and hold the buttons to move and
CHAPTER 10
The inferno operating system can be used in number of daily life uses , like telephony, in
which it can be used for the set up of call as well as controlling the devices used in
telephony. It can also be proved helpful in converting any text into speech format. The
major use of this operating system can be used in the network gateways. This os can be
used to control the IP switch/router for voice and data being developed by different labs
research and Network Systems organizations. An Inferno-based firewall can also be used
CHAPTER 11
CONCLUSION
Consulting in Ramsey, NJ, noted, "I am not sure this is an apples-to-apples comparison.
Inferno does have a full-blown operating system and a virtual machine and a protocol
stack, and in a lot of respects is something Java would like to be when it grows up. It is
also a complement to Java because you will be able to run Java applications within
Inferno. There is extraordinary value if Lucent is successful in positioning Java with the
telephone companies as a platform for allowing the reality of write it once and play it
anywhere on anything."
"Inferno is a unique network operating system that adapts to whatever you plug
Ritchie, one of the developers of C and currently head of system software research at
Lucent. "Imagine the ease and flexibility of a world in which you can get your e-mail
virtually anywhere, from any machine -- on your PC at the office, from a screen phone in
One of the most significant differences between Inferno and other operating
systems such as JavaOS is the way in which Inferno presents network resources to an
accessed as if it were a file in a traditional hierarchical file system (like Unix). (Inferno's
different services are joined into a single private hierarchical name space. The Styx
communications protocol is used to access all local and external resources. Since it can
run on top of TCP/IP, PPP, and ATM, Styx can be deployed easily across existing
networks.) In Java, Internet resources must be accessed indirectly by making a call to the
server.
REFERENCES
[3]. http://code.google.com/p/inferno-ds
[4].www.vitanuova.com