INTRO(1) INTRO(1)
NAME
intro - introduction to Inferno
DESCRIPTION
Inferno is a virtualised operating system that can run
natively across a wide range of processor architectures or
hosted on a wide range of operating systems. The principal
components of the system are:
• The Inferno kernel which can run both native and
`hosted' on a range of platforms and which presents the
same interface to programs in both cases.
• The Dis virtual machine.
• Styx - the tiny broad-spectrum file service protocol.
• Limbo - a new simple, modular, concurrent programming
language.
• Tk and Prefab - graphical user interface (`GUI')
primitives without a lot of goo.
• The portable cross-development suites that allow any
native Inferno platform to be cross-compiled on any
hosted system.
Manual conventions
Throughout this volume, manual entries are cross referenced
by a notation of the form entry(n), where entry is the name
of the page (in italics) and n is the manual section holding
the page. The same name may be found in more than one sec-
tion. For example, the environment variable inspection com-
mand documented in env(1), is quite distinct from the module
interface to environment variables which is documented in
env(2), which in turn is distinct from the component docu-
mented by env(3), which describes the underlying device that
implements environment variables.
Pathnames are understood to exist in the file system space
visible from Inferno. The root of this space when viewed
from the host operating system is the Inferno installation
directory, sometimes called the Inferno root directory.
Unless otherwise enabled, the result of changes made by
Inferno programs to files in the file system space is gener-
ally restricted to this portion of the host file system.
Name spaces
One of the great strengths of Inferno is the name space
interface to the resources available to a process, a
Page 1 Plan 9 (printed 11/17/24)
INTRO(1) INTRO(1)
hierarchical structure which looks very similar to a conven-
tional file system. Resources look like files and directo-
ries that can be read and written, created and deleted in a
way familiar to most programmers.
While this interface is used to provide programs with access
to conventional disk-based filestore, it is also used to
control devices and user level programs mounted in a
process's name space. Once a program or a device has been
attached to a process's name space, the program or device
interprets any access to the attachment point; it can syn-
thesise on demand the names of new files or directories,
create their contents on the fly as the process reads from
them, and interpret written data as commands or data as
appropriate (See bind(1) and sys-bind(2)).
Each new Inferno process inherits its parent's name space,
but it can divorce its own name space from that of its par-
ent (see sys-pctl(2)), giving programs the capability to
attach resources to their own name space without making them
globally visible. This per-process name space is potent but
potentially confusing, so, to help programs that might be
confused, namespace(4) gives some conventions that should be
adhered to if programs are to work properly. (That page also
gives a general overview of the Inferno source tree.)
Start up
See ``Installation of the Inferno Software'' in Volume 2 for
details of how to start up Inferno.
Window/development environment
Inferno provides a powerful development environment in which
to write, compile, execute and debug programs written in the
Limbo language. It gives the developer a clean platform
from which he can utilise an operating system which contains
many new and innovative ideas and some, carefully chosen,
older concepts that have survived the test of time and are
likely to be familiar to most Plan 9 or Unix users.
Superficially, the Inferno shell sh(1) looks and behaves
much like its Plan 9 or Unix contemporaries but, at heart,
it is quite different. The shell takes advantage of the
dynamic module loading services that Inferno provides to
allow it to be dynamically extended in appropriate and
interesting ways. For example, by loading the sh-tk(1) buil-
tin module, a shell script can provide all the programming
logic required to manage a Tk window with full Tk function-
ality in, surprisingly, few lines of code; by loading the
sh-file2chan(1) builtin module, a shell script can create a
file in the name space whose properties are completely under
the control of the script.
Page 2 Plan 9 (printed 11/17/24)
INTRO(1) INTRO(1)
The Inferno window manager wm(1) allows the user to manage
the order and position of a dynamic collection of applica-
tion windows in which to perform various tasks. Acme(1) is
targeted at programmers. It is an editor, a shell and window
system all rolled into one, which through thoughtful and
consistent application of simple principles results in a
rich and productive programming environment with a user
interface that feels right. Acme requires a three-button
mouse and attaches distinct functions to the three mouse
buttons and, indeed, to chords of buttons to maximise the
productivity of the programmer's mouse. For more details of
the Acme user interface see the paper "Acme: A User Inter-
face for Programmers" in Volume 2.
Limbo programs are compiled with limbo(1). This compiles
Limbo source into a machine-independent format (Dis) for
execution by the Inferno Dis virtual machine. The virtual
machine is designed to provide safe execution of programs
even on machines without memory protection. Debugging is
made straightforward by use of either stack(1) , to display
the execution stack of a process or, if a finer inspection
is required, wm-deb(1), a novel window based debugger that
allows the user to identify the exact location of problems,
set break points and walk the data structures of any module
loaded by the program. See "Program Development in Inferno"
in Volume 2 for details on how to use the development tools
that Inferno provides.
SEE ALSO
Section (1) (this section) for the commonly-used commands.
Section (2) for Limbo modules, including Inferno's system calls.
Section (3) for kernel devices (accessed by `bind').
Section (4) for file services (accessed by `mount').
Section (5) for the Styx file service protocol.
Section (6) for file formats and system conventions.
Section (7) for databases and database access modules.
Section (8) for administrative modules and system services.
Section (9) for the reference for Inferno's Tk variant, Limbo/Tk.
Section (10) for the build environment and device driver implementation.
Volume 2 contains papers and other documentation about Inferno.
The back of this volume contains a permuted index.
DIAGNOSTICS
Programs (modules) that wish to return error status to the
command interpreters sh(1) and mash(1) do so by executing a
sys-raise (see sys-exception(2)) with an error string start-
ing with `fail:'. On successful execution, a process can
simply exit.
SEE ALSO
Page 3 Plan 9 (printed 11/17/24)
INTRO(1) INTRO(1)
intro(2), intro(3), intro(4), intro(5), intro(6), intro(7),
intro(8), intro(9), intro(10)
Page 4 Plan 9 (printed 11/17/24)