PLANB(1) PLANB(1)
NAME
planb - introduction to Plan B 4th edition
DESCRIPTION
Plan B is an attempt to build a system designed for dynamic
distributed environments and provide a convenient computing
environment. In a Plan B environment, a user has multiple
machines and devices. Machines are assumed to be volatile,
they may come and go while the user is using the system.
The environment is made of the set of available machines.
For example, after starting a player at a machine nearby,
the user requests to play songs would be serviced by that
player. Also, the keyboard and mouse at hand are used with
any machine and not just with the one they are attached to.
Resources are exported to the network as file trees. User
programs and machines may import any resource from the
network by either importing a particular file tree or asking
the system to import a file tree with a given name and
attributes. The system tries to satisfy the import requests
made and maintains a name space that maps names to
particular trees that match the given name and attributes.
If one such trees becomes unavailable, the sytem picks up
another (matching) one as a replacement.
Most of the code of the system and most of the system
applications and libraries are those of Plan 9. This edition
of Plan B runs as a set of user programs on top of a Plan 9
system. In this manual, only pages that are specific for
Plan B refer to the system by that name. Pages that
correspond to things unchanged, ie. taken verbatim from Plan
9, still refer to the system as Plan 9. Plan 9 manual pages
that describe elements that have a preferred alternative in
Plan B, explicitly state this. After reading this page,
intro(0) is a good thing to read.
System Organization
In Plan B, all the machines are considered peers and usually
run the same system software. Any machine (running Plan B or
otherwise) may export a resource to the Plan B network and
behave as a resource server. In particular, we use services
from Plan 9 authentication servers, Plan 9 file servers,
Linux tools as voice synthesis device servers, etc.
Users own multiple Plan B terminals. Most of them are quite
capable of performing heavy computing and equipped with
large grahical displays. Each one of the terminals is owned
by a single user who customizes it to import the desired
kind of resources from those available.
Page 1 Plan 9 (printed 12/21/24)
PLANB(1) PLANB(1)
The I/O devices available, e.g. mouses and keyboards, may be
used to operate with any of the user machines. In the same
way, file viewers and other programs may be started at dif-
ferent machines and work together with the rest of the envi-
ronment using their name space.
Once users have shown their preferences by building a name
space, the system is responsible for adapting to the changes
of the environment. For most tasks, users can forget about
where to run processes, where to start interfaces, which
file trees should be mounted, when should services be
mounted/unmounted, and so on.
Name Spaces, Resources, and Volumes
There are a number of Plan B services available, each of
which is provided by one or more trees of files. Each file
tree has a global name and a set of attributes to reflect
properties of interest. Each file tree is referred to as a
volume. For example, audio playing is a service, which pro-
vides a file tree to play audio. Each file tree exported to
the network to provide an interface for audio playing is a
an audio player volume.
Therefore, in Plan B, (like in Plan 9), almost all objects
look like files. The object retrieved by a given name is
determined by a namespace that maps names to files. See
namespace(4) for the conventions used. Each process can
independently customize its namespace. This is done by
binding or mounting volumes (or subtrees of volumes) to
names in the name-space-so-far. Typically, a user starts
with a name space providing volumes for the conventional
file tree for the system, and then binds volumes onto parts
of it. Volumes can be bound explicitly, or by requesting to
the system to bind them as they become available.
Plan B has union directories: directories made of several
directories all bound to the same name, as described in
intro(1). Besides, there are volume unions where all volumes
matching the mount request are imported into a single name,
and not just one of them.
Volumes mount points are serviced by bns(4), which serves
file trees to the underlying system and hot-swaps them
according to volume availability. See the mentioned manual
page for details on how to mount and use volumes. Upon
mounting a volume, any volume that matches the name and
attributes given to mount will be mounted as it becomes
reacheable. It will be unmounted when it is no longer
reacheable. Only one of the volumes mounted at a mount point
will be used at a given time. For example, it is usual to
call mount so that any audio device volume would be bound to
/devs/audio. Although there might be multiple matching
Page 2 Plan 9 (printed 12/21/24)
PLANB(1) PLANB(1)
volumes, only one of them will be shown and used by the sys-
tem. When the volume used becomes unreachable, another one
will be picked for use.
When mounting volumes, the user specifies a volume name and
a set of attribute/value pairs. Only volumes that mach the
given name and properties will be bound by the system to the
mount point. An examle is:
mount /srv/vol /n/audio '/devs/audio user=nemo loc=136'
that imports into /n/audio any volume with name /devs/audio
owned by nemo and located at
Volumes are exported using 9P, described in section 5 of
this manual, like any other Plan 9 file tree. All Plan B
servers read and respond to 9P requests to navigate through
a file tree and to perform operations such as reading and
writing files within the tree.
The volume discovery protocol is implemented by bns(4) and
adsrv(8) and is used to discover which volumes are available
for use.
Booting
When a terminal is powered on or reset, booting proceeds
like in Plan 9, as said in booting(8). The process ends up
loading into memory a Plan 9 kernel that uses bns(4) as the
initial process. This process defines several environment
variables, that guide the boot process, sets up a name space
that mounts necessary volumes to run other programs, and
then executes the system script brc(8) and the user's pro-
file $home/lib/profile as a final step.
The environment variable $planb is set to value yes on Plan
B systems.
The file /lib/namespace.planb determines how the namespace
is built. This namespace is used to run the system start
script and the user's profile. The user's profile usually
runs the omero(1) window system as the primary user inter-
face.
Using Plan B
Using Plan B is very much like using Plan 9, although the
user can now forget about how to set up a name space for a
particular network setup. Users should tell the system what
kind of resource they want, and let the system choose a par-
ticular one to satisfy the constraints given by the user.
Otherwise, the system would not adapt to changes in resource
availability.
The user commands of Plan B are those of Plan 9 in many
cases. However, Graphical interfaces are provided by the
Page 3 Plan 9 (printed 12/21/24)
PLANB(1) PLANB(1)
omero(4) service, which provides portable widgets. Command
execution is performed through the portfs(4) network messag-
ing service, by sending requests to the exec port, which
works for remote machines as well.
The same happens to the programming interface documented in
section 2. Most notably, readf(2) is the preferred way for
file I/O, instead of the venerable read(2) interface. User
interface programming should rely in omero(2) and not in
control(2) or draw(2). There are other changes in the API
that are important to easy adaptation to environment
changes. The system is just born and interfaces are still
evolving quickly, beware of that.
Physical Environment
Context information is available at /what, /who, and /where.
Services to operate and inspect the physical environment are
available at several directories mounted under /devs. The
environment is handled by tools descrived in env(8) and
other programs.
User Input
The character-delete character is backspace, and DEL is the
interrupt character: typing it sends an interrupt to pro-
cesses running in that window. Control is usually the
caps-lock key, and the left control, start, and alt buttons
are usually equivalent to the three buttons found in the
mouse. The menu key permits character composition. See
keyboard(6) for instructions.
The standard editor is ox(1), which works in omero(1) panels
and integrates well with the rest of the Plan B system.
Devices and Volumes
The devices in Plan B are those of Plan 9, described in sec-
tion 3. But beware that for some devices, most notably
graphics, text and mouse I/O, audio, and command execution,
there are other (preferred) servers documented in section 4
of this manual. Such servers provide a high-level interface
designed for applications, and are more portable and adapta-
tive than the ones described in section 3 of the manual.
It is advisable to check first section 4 when looking for a
service, before resorting to the low level interface pro-
vided by native devices. Note that devices in section 3 com-
pletelly circunvent the name space and lead to name spaces
that do not adapt to changes in resouce volumes availabil-
ity.
A Plan 9 file server provides a file tree to processes. A
Plan B file server is similar, but is usually implemented to
provide a volume that can be used with the volume mounting
Page 4 Plan 9 (printed 12/21/24)
PLANB(1) PLANB(1)
facility. This means that the server has options to start
servicing network requests, announce the volume, and has
authentication implemented. Authentication is only requested
for connections from remote machines, because the volume
owner is the terminal owner in a Plan B installation. See
planb(4) for a description of Plan B volume file servers and
other conventions regarding the name space. Conventions
regarding attributes for volumes are described in cnstr(6).
SEE ALSO
intro(1) for a description of the underlying Plan 9 system.
planb (4) for a description of Plan B conventions regarding
volume servers and name spaces.
/sys/doc/9 for white papers on Plan 9 (which of course can
still apply to Plan B), and /sys/doc/papers for copies of
Plan B papers that might be of help.
BUGS
The system is just born. Bugs are found now and then, but
the system is stable enough to let us use it as our develop-
ment platform and to perform our daily work. Most good
things come from Plan 9, most bugs are ours instead.
Page 5 Plan 9 (printed 12/21/24)