Forwarded-by: "Rob Pike" <rob@plan9.bell-labs.com>
Inferno: la Commedia Interattiva
Inferno(TM) is an operating system for delivering interactive
media to its users. It is under development within the Com-
puting Science Research Center of Bell Labs at Lucent Tech-
nologies.
Inferno is intended to be used in a variety of emerging
network environments, for example in TV set-top boxes
attached to cable systems, advanced telephones, hand-held
devices, and inexpensive networked computers, but also in
conjunction with traditional computing systems.
The most visible such environments involve cable televi-
sion, direct satellite broadcast, and the Internet. 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 net-
works will develop in a world of diverse terminals, network
hardware, and protocols. Only a well-designed, economical
operating system can insulate the various providers of con-
tent and services from the equally varied transport and pre-
sentation platforms. Inferno is a research project to build
a network operating system for this new world.
Inferno's definitive strength lies in its portability and
versatility across several dimensions:
o Portability across processors: it currently runs on Intel,
MIPS, and AMD 29K architectures and is readily portable to
others.
o Portability across environments: it runs as a stand-alone
operating system on IBM-compatible PCs and on a 29K-based
palm-top machine; it also runs as a user application under
Unix, Windows NT, Windows 95, and Plan 9. All of these
environments present an identical interface to Inferno
applications.
o Distributed design: an identical environment is estab-
lished at the user's terminal and at the server, and each
may import the resources of the other; aided by the commu-
nications facilities of the run-time system, applications
may be split easily (and even dynamically) between client
and server.
o 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.
o Portable applications: Inferno applications are written in
the type-safe language Limbo(TM), whose binary representation
is identical over all platforms.
o Dynamic adaptability: applications may, depending on the
hardware or other resources available, load different pro-
gram modules to perform a specific function. For example,
a video player application might use any of several dif-
ferent decoder modules.
Underlying the design of Inferno is a model of the diver-
sity of application areas it intends to stimulate. Many
providers are interested in purveying media and services:
WWW servers, cable companies, merchants, various information
providers. There are many ways of connection: ordinary
telephone modems, ISDN, 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 in consumers' homes: PCs, game
consoles, newer set-top boxes. 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. One reason is the cost of the set-top, espe-
cially its memory requirements.
Inferno is parsimonious enough in its resource require-
ments to support interesting applications on today's hard-
ware, 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, and includes video clips over digital
cable.
Clearly not everyone who deploys an Inferno-based solution
will want to span the whole range of possibilities, but this
range should be constrained only by the desired markets and
the available interconnection and server technologies, not
by the software.
Inferno interfaces
The role of the Inferno system is to create several stan-
dard interfaces for its applications:
o Applications use various resources internal to the system,
such as a consistent virtual machine that runs the appli-
cation programs, together with library modules that per-
form services as simple as string manipulation through
more sophisticated graphics services for dealing with
text, pictures, and video.
o Applications exist in an external environment containing
resources such as data files that can be read and manipu-
lated, together with objects that are named and manipu-
lated like files but are more active. Devices (for exam-
ple a hand-held remote control, an MPEG decoder or a net-
work interface) present themselves to the application as
files.
o Standard protocols exist for communication within and
between separate machines running Inferno, so that appli-
cations can cooperate.
At the same time, Inferno uses interfaces supplied by an
existing environment, either bare hardware or standard oper-
ating systems and protocols.
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. Of course the information
flow is not one-way: the user's terminal (whether a network
computer, TV set-top, PC, or videophone) is also an informa-
tion source and its devices represent resources to applica-
tions. Inferno draws heavily on the design of Plan 9 in the
way it presents resources to these applications.
The design has three principles. First, all resources are
named and accessed like files in a forest of hierarchical
file systems. Second, the disjoint hierarchies provided by
different services are joined together into a single private
hierarchical name space. Third, a communication protocol,
called Styx, is applied uniformly to access these
resources, whether local or remote.
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.
As in Plan 9 and, to a lesser extent, Unix, devices are rep-
resented as files, and device drivers (such as a serial
port, an MPEG decoder, a network interface, or the TV
screen) attached to a particular hardware box present them-
selves as small directories. These directories typically
containing two files, data and ctl, which respectively
perform actual device I/O and control and status 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 return the corresponding
numeric Internet address.
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 inter-
nal resources respond to the procedural version of Styx.
The Inferno kernel implements a mount driver that trans-
forms file system operations into remote procedure calls for
transport over a network. On the other side of the connec-
tion, 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 another 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.
Internal Environment of Inferno Applications
Inferno applications are written in a new language called
Limbo, which was designed specifically for the Inferno envi-
ronment. 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.
In addition, Limbo supplies several advanced constructs
carefully integrated into the Inferno virtual machine. In
particular, a communication mechanism called a channel is
used to connect different Limbo tasks on the same machine or
across the network. A channel transports typed data in a
machine-independent fashion, so that complex data structures
(including channels themselves) may be passed between Limbo
tasks or attached to files in the name space for language-
level communication between machines.
Multi-tasking is supported directly by the Limbo language:
new, independently 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 communi-
cate). 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 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 state-
ment 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 adaptabil-
ity. 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 unavailable, the
video-decoder module is never loaded.
Limbo is carefully type-checked at compile- and run-time;
for example, pointers, besides being more restricted than in
C, are checked before being dereferenced, and the type-
consistency of a dynamically loaded module is checked when
it is loaded. Limbo programs run safely on a machine with-
out memory-protection hardware. Moreover, all Limbo data
and program objects are subject to a garbage collector,
built deeply into the Limbo run-time system. The garbage
collector uses reference counting and applies to all system
resources. For example, when an application task that has
created a graphics window terminates, the window automati-
cally disappears because the last reference to it has gone
away.
Limbo programs are compiled into byte-codes representing
instructions for a virtual machine called Dis(TM). The archi-
tecture of the arithmetic part of Dis resembles a simple
RISC-oriented register machine, supplemented with a few spe-
cialized operations for handling some of the higher-level
data types like arrays and strings. Garbage collection and
the associated mechanism for keeping reference counts are
handled below the level of the machine language; similarly
the multitasking primitives are hidden below the surface.
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 exe-
cutes 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 man-
agement, scheduling, device drivers, protocol stacks, and
the like. The kernel also contains the core of the file
system (the name interpreter and the code that turns file
system operations into remote procedure calls over communi-
cations links) as well as the small file systems implemented
internally.
Finally, the Inferno virtual machine implements several
standard modules internally. These include Sys, which pro-
vides system calls and a small library of useful routines
(e.g. creation of network connections, string manipula-
tions). Module Draw is a basic graphics library that han-
dles 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 Prefab.
Module Tk is an all-new implementation of the Tk graphics
toolkit, with a Limbo interface. A Math module encapsu-
lates the procedures for numerical programming.
The Environment of the Inferno System
Inferno creates a standard environment for applications.
Identical application 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 device driver
set.
When running as the native operating system, the kernel
includes all the low-level glue (interrupt handlers, graph-
ics and other device drivers) needed to implement the
abstractions presented to applications. For a hosted sys-
tem, for example under Unix, Windows NT or Windows 95,
Inferno runs as a set of ordinary processes. Instead of
mapping its device-control functionality to real hardware,
it adapts to the resources 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 oper-
ating systems under which it can run.
Security
Inferno is secure against erroneous or malicious applica-
tions, and encourage safe collaboration between mutually
suspicious service providers and clients. Its internal
security at the instruction level is enforced by a combina-
tion of Limbo type-checking and the Dis engine. At a higher
level, resources available to applications all appear exclu-
sively in the name space of the application. 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 a controlled,
authenticated operation.
Inferno also provides communications security and key man-
agement. Each communication channel may be transmitted in
the clear, accompanied by message digests to prevent corrup-
tion, 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 mech-
anisms (e.g. ElGamal); after key exchange, message digesting
and line encryption likewise use standard symmetric-key
mechanisms (MD5, SHA, DES).
(C) 1996 Lucent Technologies Inc.