pplications run in only 1 MB of RAM, making it suitable for embedded systems, such as network computers (NCs), set-top boxes, and PDAs.
However, the system's hardware-abstraction architecture (described below) makes it an ideal interface for high-performance server applications. For example, it allows an Internet service provider (ISP) to write mission-critical software that runs on a server farm using different hardware and host OSes.
The Inferno OS was designed to support a "write once, run many" model for software developers. That is, a compiled Inferno program can run on a variety of existing and emerging hardware systems. The Inferno system employs several layers of abstraction to achieve this ubiquity. Inferno provides a virtual machine (VM) to hide hardware architectural differences so that software isn't tied to any specific processor. So far, this sounds a lot like Java, but Inferno goes further than this single lay
er of abstraction by providing a virtual OS (VOS) and a virtual network (VN).
The Abstract OS
The idea of a VOS is analogous to a VM. Inferno's VOS defines a common interface for system services. Support for this common interface is achieved in two different ways. First, the VOS can reside, or be hosted, on top of an existing OS (as in the server-farm example above). In this case, the interface maps VOS services to the native OS services. Alternatively, the VOS can be made "real" through a kernel that implements the VOS interfaces directly on the hardware, as shown in the figure
"Inferno Architecture"
.
The VN is the next layer of abstraction. Currently, many properties of the type and topology of a network are embedded in applications. For instance, many programs that use the sockets-communications library contain information that ties the software to the IP protocol.
Inferno provides a single abstract view of the network. Network nodes are accessed ge
nerically via a symbolic machine and service name. The Inferno system then takes care of the specifics of the underlying network -- for example, TCP or asynchronous transfer mode (ATM). All the virtual components work together to make the applications software independent of the underlying network infrastructure. You could upgrade a network to, say, Gigabit Ethernet without rewriting the applications software, thereby increasing its useful lifetime and reducing support costs.
File System and Namespaces
Inferno has many of the features you would expect to find in a modern OS, as well as some unique features. Conventional features found in Inferno include threads, device access, and a networking file system. Among Inferno's unique features, two stand out: First, all resources are represented as file systems. Second, local and remote file systems can be placed in a dynamically configurable, hierarchical namespace.
Inferno file systems contain entries that represent actual disk file
s. These systems also contain entries representing resources, which appear as files. For example, hardware resources, such as a display or a network device, appear as files to an application. This abstraction is powerful because of its simplicity and familiarity. You access resources through familiar function calls, such as
open()
,
read()
, and
write()
. Furthermore, all resources can be assigned access permissions and ownership.
This interface is both simple to use and simple for the system to support. A network interface allows any Inferno file system (i.e., resource) to be exported to other Inferno nodes on a network. Therefore, when an application performs file-access operations, it does not require the file to be local or remote (see the figure
"Inferno Resources"
).
Each thread in Inferno inherits a namespace, which can be dynamically configured and subsequently passed on to its siblings. A
namespace
is a hierarchical collection of files
on both local and remote file systems that are available to a program. An application can require a particular namespace or construct one on its own. How that namespace is constructed -- that is, where it is or what resources are actually present -- can be unknown to the application. Furthermore, namespaces can change from one invocation to the next, or even during execution. This allows resources to be configured, reconfigured, and modified without disturbing the application code.
The Styx Protocol
Inferno relies on a number of underlying technologies to operate. In compliance with Inferno's mythological underworld theme, its key component for distributed nature is called Styx. Styx uses a simple message-oriented protocol that resides on top of a reliable, in-order, network-ing protocol, such as TCP. It implements the basic operations, such as open, read, write, and close, necessary to operate on files. Thus, Inferno makes local procedure calls if the file system being accessed is lo
cal. Otherwise, the Inferno kernel automatically converts the file-system calls into appropriate Styx messages and sends them to the remote host.
Each Styx message can optionally contain a cryptographic signature and/or be encrypted. This fundamental integration of security within Inferno satisfies the commercial requirements of networking systems. Inferno nodes connecting to one another are authenticated using public-key-encryption schemes, thus creating a trusted network environment.
The Dis VM
The Dis VM implements a software processor for the Inferno system. This provides applications with a common target instruction set and architecture. The instruction set for Dis is not specific to any language. Each instruction consists of one byte that identifies the instruction operation, and another that identifies the addressing mode. The instruction is followed by three optional operands ranging in size from 1 to 4 bytes each.
Dis supports several high-level data types -- stri
ngs, arrays, lists, and channels -- and operators to manipulate them. It also supports threads, interthread communication, and automatic garbage collection. Like Java, Dis prevents you from manipulating pointers or accessing arbitrary memory locations, and it foils any attempt to use null pointers.
The garbage-collection scheme that Dis uses is a hybrid approach, consisting of reference-counting augmented by a concurrent mark-and-sweep collector. Unlike with Java, Dis's garbage collector deals with resources: It can clean up unused files, windows, and client/server connections.
When a Dis module is loaded, it can be either interpreted directly or just-in-time (JIT) compiled. The JIT compiler translates the Dis instructions into the equivalent native code of the underlying architecture. JIT compilers are relatively small and easy to write because they were conceived before the Dis instruction set was formulated.
Developing for Inferno
The Inferno system also includes Limbo,
a new general-purpose, concurrent programming language. Limbo is a strongly typed dynamic language designed to take advantage of Inferno's features. Developers familiar with the C language will be very comfortable with the syntax and semantics of Limbo.
Along with the Limbo language comes a large set of application-level services, which include the Tk graphics library, file manipulation, math functions, linear algebra, encryption, string-parsing, and more. The Inferno distribution also contains a set of applications and numerous sample programs. The bundled applications include an editor, a debugger, and a compiler.
Inferno Resources
Additional information on Inferno can be obtained from Lucent Technologies' Inferno Web site (
http://www.lucent.com/inferno
). This site contains the
Inferno evaluation release 1.0 package for downloading.
Inferno: One Hot OS
