[Top] [Prev] [Next]

Limbo System Modules

The Limbo system modules are as follows:

System Modules



change file name space



convert between bytes and characters


change working directory



export, listen

make network connections


read directory


duplicate an open file descriptor


create file connected to Limbo channel


millisecond timer



open/create a file for reading or writing


process control


print formatted output

fprint, sprint



read or write file


remove a file


change file offset


delay execution


fstat, fwstat,

stat, wstat

get and put file status


split string into words


compute the Unicode length of a UTF byte sequence


include "sys.m";
sys:= load Sys Sys->PATH;


File Name Space

Files are collected into a hierarchical organization called a file tree starting in a directory called the root. Filenames, also called paths, consist of a number of / -separated "path elements with the slashes corresponding to directories. A path element must contain only printable characters (those outside ASCII and Latin-1 control space). A path element cannot contain a space, slash, or #. The path element ".." refers to the parent directory of the directory containing that element.

When a process presents a file name to Inferno, it is evaluated by the following algorithm.

Start with a directory that depends on the first character of the path:

/ means the root of the main hierarchy,

# means the separate root of a kernel device's file tree (see Section 3),

and anything else means the process's current working directory.


For each path element, look up the element in the directory, advance to that directory, do a possible translation (see below).


Repeat. The last step may yield a directory or regular file.

The collection of files reachable from the root is called the name space of a process.

A program can use bind or mount (see bind) to say that whenever a certain (specified) file is reached during an evaluation, that evaluation continues instead from some other (specified) file. These same calls create union directories, which are concatenations of ordinary directories that are searched sequentially until the desired element is found.

The result of evaluating ".." in a union directory is undefined.

Using bind and mount to do name space adjustment affects only the current name space group (see below, and pctl).

Certain conventions about the layout of the name space must be preserved.

File I/O

Files are opened for input or output by open or create (see open). These calls return a reference to an object of type FD (file descriptor) that identifies the file to subsequent I/O calls, notably read and write (see read). The FD contains an integer file descriptor, but the FD type is passed to Limbo I/O routines. When the last reference to an FD disappears, the file is descriptor is released by the garbage collector.

Integer file descriptor values range from 0 to n where the upper bound depends on the underlying operating system. The system allocates the numbers by selecting the lowest unused descriptor. They may be reassigned using dup (see dup). Integer file descriptor values are indices into a kernel-resident file descriptor table, which is inherited from the parent when a process is created by a Limbo spawn operation. A set of processes, called a file descriptor group, shares that table, so files opened by one process may be read and written by other processes in the group. (See pctl).

By convention, file descriptor 0 is the standard input, 1 is the standard output, and 2 is the standard error output. The operating system is unaware of these conventions. It is possible to close file 0, or even to replace it by a file open only for writing, but programs written according to the normal convention will be confused by such chicanery.

Files are normally read or written in sequential order. The I/O position in the file is called the file offset and may be set arbitrarily using the seek system call (see seek).

Directories may be opened and read much like regular files (see dirread). They contain an integral number of records, called directory entries. Each entry is a machine-independent representation of the information about an existing file in the directory, including the name, ownership, permission, access dates, and so on.

The entry corresponding to an arbitrary file can be retrieved by stat or fstat (see stat); wstat and fwstat write back entries, thus changing the properties of a file.

New files are made with create and deleted with remove (see open and remove).

Directories are manipulated by create, remove, wstat, and fwstat; they may not directly be written.

Inferno provides no guarantee of consistency should several processes access a file concurrently. Guaranteed synchronous writes are not available.

Atomicity is guaranteed for I/O with byte counts smaller than the Styx message size; see read.

Process execution and control

A Limbo process, also called a thread, is the basic unit of computation for Limbo application programming in the Inferno system.

A newly spawned thread shares the same address space as that of its creator thread. That is, the set of global variables that is in scope to one is in scope to the other. A change made by one can be detected by the other. Since they are scheduled independently, they should synchronize their actions to share this data meaningfully.

The newly created thread also shares the same set of open file descriptors and the current working directory.

Processes are also organized into process groups that typically represent the set of threads of a single application and can be terminated by a single kill request; see prog.

It is possible for a thread to acquire a new, independent name space and set of file descriptors. See pctl.

User/Group Identity

Inferno maintains user identifier (uid) and group identifier (gid) strings for each process. These values are also attributes of files and directories. See stat and stat. A comparison of process and file identities take place when a process attempts to open or create a file.

When a pathname crosses from one server to another the process identities are mapped by each server receiving a file request.

The uid and gid strings are assigned to the thread that is created when a user logs into Inferno and cannot be changed.

[Top] [Prev] [Next]

Copyright © 1996,Lucent Technologies, Inc. All rights reserved.