The Limbo system modules are as follows:

System Modules

bind mount, unmount	change file name space
byte2char char2byte	convert between bytes and characters
chdir	change working directory
dial announce, export, listen	make network connections
dirread	read directory
dup	duplicate an open file descriptor
file2chan	create file connected to Limbo channel
millisec	millisecond timer
open create	open/create a file for reading or writing
pctl	process control
print	print formatted output
fprint, sprint
read write	read or write file
remove	remove a file
seek	change file offset
sleep	delay execution
stat fstat, fwstat, stat, wstat	get and put file status
tokenize	split string into words
utfbytes	compute the Unicode length of a UTF byte sequence

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

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

1.	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.
2.	For each path element, look up the element in the directory, advance to that directory, do a possible translation (see below).
3.	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

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 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

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.