[manual index][section index]


namespace - structure of conventional Inferno name space




The list below gives an overview of the Inferno distribution file tree, organised into related categories.

The root directory. To programs running outside Inferno, this corresponds to the directory in which Inferno has been installed (e.g. C:\inferno under Windows).

Mount points
The following are all placeholders for filesystems that are mounted when Inferno is running. They contain no data files. Although an Inferno namespace is a dynamic entity, and devices can be mounted anywhere therein, many programs assume that devices have been mounted in the standard places, as suggested by the skeleton directories listed below.

The standard mount point for devices (e.g. cons(3))
The standard mount point for the env(3) device.
A directory containing mount points for applications.
An empty directory, used for holding files created with sys-file2chan(2).
The standard mount point directory for network interfaces.
A directory containing mount points for file trees on local devices or imported from remote systems.
An empty directory, the mount point for the prog(3) device.
An empty directory, the mount point for a non-volatile RAM filesystem on devices that have one.
Mount point for private directory of temporary files (eg, /usr/user/tmp).
Conventional place to mount mailboxes.

Limbo applications
Dis executables (commands)
Dis libraries
Dis commands that run under wm(1).
Manual pages.
Documentation other than manual pages.
Source to Limbo applications.
Source to the commands in /dis (as documented in Section 1).
Source to the commands in /dis/wm
Source to the modules in /dis/lib (as documented in Section 2).
Limbo module declarations

Supporting data
Programs and guide files specific to acme(1).
Font definitions
Timezone and locale information
Contains image(6) files used by programs.
Default directory searched by tk's -bitmap option (see options(9)).
Static program-specific data.
Network configuration files used by cs(8), dns(8) and others.

Storage of secrets and certificates on signers (authentication servers).
A jungle of program-specific configuration files.

Platform specific
Binaries specific to Platform. Current platforms include Inferno (native binaries), FreeBSD, Hp, Irix, Linux, Nt, Plan9, Solaris and Unixware.
Platform specific binaries, libraries and include files respectively. Arch is the architecture type, as defined in 2c(10.1) and held in the $objtype environment variable.
A directory containing user directories.

Inferno source code
Directory containing source specific to emu(1).
Cross-platform source for emu(1). /emu/Platform Platform-specific source for emu(1).
The emu version of kfs(3).
Source to libraries used by hosted commands.
Source to the Plan 9 emulation library, used by emu and the hosted commands.
Inferno source used by both native and hosted versions of Inferno.
Source to the two hosted Inferno commands of the same name.
Source to hosted utilities run from emu(1) via the cmd(3) interface.
A directory containing source directories for hosted tools used in building Inferno (e.g. mk(10.1)).
A directory holding source directories for the native versions of Inferno.
Limbo source for platform-specific initialisation procedures.
Portable native kernel source.
Arch-specific native kernel source.
The native kernel version of kfs(3).

Minimal name space
The above is all very well on a system with lots of storage, but what is actually necessary for the running of Inferno? The following gives a quick summary of the structure that must be provided for Inferno to function correctly.

This must contain Dis modules for all the applications you plan to run, and the modules they depend on. Disdep(1) can be useful when trying to determine this set.
All empty unwritable directories, place holders for mounted services and applications. Often these are provided by the built-in root(3).
A directory containing mount points for applications.
A directory containing mount points for remote file systems.

Files needed to run as a server
See keyfs(4), logind(8) and signer(8).
See createsignerkey(8) and logind(8).

Files needed to run the window manager
At least one font must be provided - a default font for Tk to use.
This should contain icons used by applications that run within Tk.
At least one user directory must exist if logon(1) is to function correctly.


intro(1), root(3), namespace(6)

NAMESPACE(4 ) Rev:  Thu Feb 15 14:43:41 GMT 2007