INTRODUCTION

Inferno is intended to be used in a variety of network environments, for example those supporting advanced telephones, hand-held devices, TV set-top boxes attached to cable or satellite systems, and inexpensive Internet computers, but also in conjunction with traditional computing systems. The most visible new environments involve cable television, direct satellite broadcast, the Internet, and other networks. As the entertainment, telecommunications, 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 operating system for this new world.

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, and PowerPC architectures and is readily portable to others. Portability across environments: it runs as a stand-alone operating system on small 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 applications see an identical interface. Distributed design: the identical environment is established at the user's terminal 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.

Minimal hardware requirements: it runs useful applications stand-alone on machines with as little as 1 MB of memory, and does not require memory-mapping hardware.

Portable applications: Inferno applications are written in the type-safe language Limbo, whose binary representation is identical over all platforms.

Dynamic adaptability: applications may, depending on the hardware or other 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.

Underlying the design of Inferno is a model of the diversity of application areas it intends to stimulate. Many providers are interested in purveying media and services: telephone network service providers, WWW servers, cable companies, merchants, various information providers. There are many connection technologies: ordinary telephone modems, ISDN, ATM, the Internet, analog broadcast or cable TV, cable modems, digital video on demand, and other interactive TV 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 these spectra, epitomized by fully interactive TV with video on demand, may be fascinating, but have developed more slowly than expected.

DESIGN PRINCIPLES
Inferno is a distributed system based on the application of three basic principles Resources as files: all resources are represented as files within a hierarchical file system Namespaces: the application view of the network is a single, coherent namespace that appears as a hierarchical file system but may represent physically separated (locally or remotely) resources Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remote

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 things, storage devices, processes, services, networks and network connections. An 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 operations such as open, read and write

Reliance on file systems reduces the amount of interface code and keeps the Inferno system small, reliable and highly portable
Naming

conventions for files are well known, uniform and easily understood

Namespace
The second key principle of Inferno is the computable namespace, by which an 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 resources accessible within an individual namespace can be located on a single client or on multiple servers throughout the network. 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 if the resource is local or remote.

Standard Communication Protocol

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 focus security, Styx provides several mechanisms for secure communication: Certificate based user authentication Message encryption

INFERNO INTERFACES
The role of the Inferno system is to create several standard interfaces for its applications: Applications use various resources internal to the system, such as a consistent virtual machine that runs the application programs, together with library modules that perform services as simple as string manipulation through more sophisticated graphics services for dealing with text, pictures, higher-level toolkits, and video. Applications exist in an external environment containing resources such as data files that can be read and manipulated, together with objects that are named and manipulated like files but are more active. Standard protocols exist for communication within and between separate machines running Inferno, so that applications can cooperate.

Inferno architecture

Fig: Inferno architecture Inferno offers a common OS interface, a VM, and a virtual network interface. Inferno has mainly three layers. They are application layer, kernel layer and hardware layer. Application layer include Limbo applications and VM. Kernel layer contain namespace, process

management, memory management, security and graphics library. Hardware layer include host os, device drivers and network interface.

APPLICATION LAYER
Limbo application program: 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. Limbo programs run safely on a machine without memory-protection hardware. Moreover, all 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 last reference to it has gone away. DisVirtualmachine: Limbo programs are compiled into byte-codes representing instructions for a 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 bytecodes are expanded into a format more efficient for execution. 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 as well as the small file Systems implemented internally. Finally, the Inferno virtual machine implements several standard modules internally. These include Sys, which provides system calls and a small library of useful routines (e.g. creation of network connections, string manipulations). Module Draw is a basic graphics library that handles raster graphics, fonts, and windows.

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 resources accessible within an individual namespace can be located on a single client or on multiple servers throughout the network. 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 if the resource is local or remote. Memory management: Among other things, a multiprogramming operating system kernel must be 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. If a program fails it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs, or viruses may purposefully 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 memory. Various methods of memory protection exist, including memory segmentation and paging. 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 synchronization among processes. To meet these requirements, the OS must maintain a 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: Inferno provides security of communication, resource control, and system integrity. Each external communication channel may be transmitted in the clear, accompanied by message digests to prevent corruption, or encrypted to prevent corruption and interception. Once communication is set up, the encryption is transparent to the application. Key exchange is provided through standard public-key mechanisms; after key exchange, message digesting and line encryption likewise use standard symmetric mechanisms. Inferno is secure against erroneous or malicious applications, and encourages safe collaboration between mutually suspicious service providers and clients.

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 with their own private key. Inferno uses encryption for: Mutual authentication of communicating parties; Authentication of messages between these parties; and Encryption of messages between these parties.

HARDWARE LAYER
Device drivers
A device driver simplifies programming by acting as a translator between a device and the applications or operating systems that use it. In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device. A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware is connected. When a calling program 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 program. Drivers are

hardware-dependent and operating-system-specific. Inferno needs a very small set of device drivers.

Host os
Inferno can run in different host operating system

Host systems
Windows NT/2000/XP Linux Mac OS Plan9os

INFERNO RESOURCES

Fig: Inferno Resources

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.

External Environment of Inferno Applications

The purpose of most Inferno applications is to present information or media to the 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 (whether a network computer, TV set-top, PC, or videophone) is also an information source and its devices represent resources to applications. Devices are represented as files, and device drivers (such as a modem, an MPEG decoder, a network interface, or the TV screen) attached to a particular hardware box present 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.

Internal Environment of Inferno Applications

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.

ADVANTAGES OF INFERNO
Cross platform integration
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.

Transparent resource access

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 resource is local or remote.

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 dont need to reimplemented by each application. Network connection may be authenticated using certificates to ensure access is only granted to authorized users.

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 GIF or 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 delete the window.

CONCLUSION
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 into it -- from a high-end workstation to an inexpensive hand-held device," In Inferno, every resource, whether it is a database or a distant computer, is 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.