Editing Plan 9 from Bell Labs (section)

== Design concepts ==
{{quote box|
 |quote = Plan 9 from Bell Labs is like the [[Quakers]]: distinguished by its stress on the 'Inner Light,' noted for simplicity of life, in particular for plainness of speech. Like the Quakers, Plan 9 does not proselytize.
 |source = —Sape J. Mullender, Pierre G. Jansen.<br />''Real Time in a Real Operating System''<ref name = "HerbertJones2004" />
 |align = right
 |width = 33%
 |salign = right}}
Plan 9 is a [[distributed operating system]], designed to make a network of [[heterogeneous computing|heterogeneous]] and geographically separated computers function as a single system.<ref name = "reinventing-unix" /> In a typical Plan 9 installation, users work at terminals running the window system [[rio (windowing system)|rio]], and they access CPU servers which handle computation-intensive processes. Permanent data storage is provided by additional network hosts acting as file servers and archival storage.<ref name= "distributed-system" />

Its designers state that,

{{Blockquote|[t]he foundations of the system are built on two ideas: a per-process [[namespace|name space]] and a simple message-oriented file system protocol.|Pike ''et al.''{{r|use-of-namespaces}}}}

The first idea (a per-process name space) means that, unlike on most operating systems, [[Process (computing)|processes]] (running programs) each have their own view of the ''namespace'', corresponding to what other operating systems call the file system; a single path name may refer to different resources for different processes. The potential complexity of this setup is controlled by a set of conventional locations for common resources.{{r|welch}}{{r|man4namespace}}

The second idea (a message-oriented filesystem) means that processes can offer their services to other processes by providing virtual files that appear in the other processes' namespace. The [[client–server model|client]] process's input/output on such a file becomes [[inter-process communication]] between the two processes. This way, Plan 9 generalizes the Unix notion of the [[Unix filesystem|filesystem]] as the central point of access to computing resources. It carries over Unix's idea of [[device file]]s to provide access to peripheral devices ([[computer mouse|mice]], removable media, etc.) and the possibility to [[mount (Unix)|mount]] filesystems residing on physically distinct filesystems into a hierarchical namespace, but adds the possibility to mount a connection to a server program that speaks a standardized protocol and treat its services as part of the namespace.

For example, the original window system, called 8½, exploited these possibilities as follows. Plan 9 represents the user interface on a terminal by means of three pseudo-files: {{mono|mouse}}, which can be read by a program to get notification of mouse movements and button clicks; {{mono|cons}}, which can be used to perform textual input/output; and {{mono|bitblt}}, writing to which enacts graphics operations (see [[bit blit]]). The window system multiplexes these devices: when creating a new window to run some program in, it first sets up a new namespace in which {{mono|mouse}}, {{mono|cons}} and {{mono|bitblt}} are connected to itself, hiding the actual device files to which it itself has access. The window system thus receives all input and output commands from the program and handles these appropriately, by sending output to the actual screen device and giving the currently focused program the keyboard and mouse input.{{r|distributed-system}} The program does not need to know if it is communicating directly with the operating system's device drivers, or with the window system; it only has to assume that its namespace is set up so that these special files provide the kind of input and accept the kind of messages that it expects.

Plan 9's distributed operation relies on the per-process namespaces as well, allowing client and server processes to communicate across machines in the way just outlined. For example, the {{mono|cpu}} command starts a remote session on a computation server. The command exports part of its local namespace, including the user's terminal's devices ({{mono|mouse}}, {{mono|cons}}, {{mono|bitblt}}), to the server, so that remote programs can perform input/output using the terminal's mouse, keyboard and display, combining the effects of [[remote login]] and a shared network filesystem.{{r|distributed-system}}{{r|use-of-namespaces}}

=== 9P protocol ===
{{Main |9P (protocol)}}

All programs that wish to provide services-as-files to other programs speak a unified protocol, called 9P. Compared to other systems, this reduces the number of custom [[application programming interface|programming interfaces]]. 9P is a generic, medium-agnostic, [[byte-oriented]] protocol that provides for messages delivered between a server and a client.<ref name="unix-spirit-set-free" /> The protocol is used to refer to and communicate with processes, programs, and data, including both the user interface and the network.<ref name="not_dead" /> With the release of the 4th edition, it was modified and renamed 9P2000.<ref name="osnews-4th-edition-release" />

Unlike most other operating systems, Plan 9 does not provide special [[application programming interface]]s (such as [[Berkeley sockets]], [[X resources]] or [[ioctl]] system calls) to access devices.<ref name="unix-spirit-set-free" /> Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file [[input/output]] operations ''read'' and ''write''. Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.<ref name="taoup" />

=== Union directories and namespaces ===
{{anchor|Union directory|Name}}
Plan 9 allows the user to collect the files (called ''names'') from different directory trees in a single location. The resulting ''[[Union (set theory)|union]] directory'' behaves as the concatenation of the underlying directories (the order of concatenation can be controlled); if the constituent directories contain files having the same name, a listing of the union directory ({{mono|ls}} or {{mono|lc}}) will simply report duplicate names.{{r|valerie-aurora}} Resolution of a single path name is performed top-down: if the directories {{mono|top}} and {{mono|bottom}} are unioned into {{mono|u}} with {{mono|top}} first, then {{mono|u/name}} denotes {{mono|top/name}} if it exists, {{mono|bottom/name}} only if it exists ''and {{mono|top/name}} does not exist'', and no file if neither exists. No recursive unioning of subdirectories is performed, so if {{mono|top/subdir}} exists, the files in {{mono|bottom/subdir}} are not accessible through the union.{{r|4.4bsd}}

A union directory can be created by using a sequence of {{mono|bind}} commands:

<pre>
bind /arm/bin /bin
bind -a /acme/bin/arm /bin
bind -b /usr/alice/bin /bin
</pre>

In the example above, {{mono|/arm/bin}} is mounted at {{mono|/bin}}, the contents of {{mono|/arm/bin}} replacing the previous contents of {{mono|/bin}}. [[Acme (text editor)|Acme]]'s {{mono|bin}} directory is then union mounted after {{mono|/bin}}, and Alice's personal {{mono|bin}} directory is union mounted before. When a file is requested from {{mono|/bin}}, it is first looked for in {{mono|/usr/alice/bin}}, then in {{mono|/arm/bin}}, and then finally in {{mono|/acme/bin/arm}}.

The separate process namespaces thus usually replace the notion of a [[PATH (variable)|search path]] in the shell. A path environment variable ({{code|$path}}) still exists in the [[Rc (Unix shell)|rc]] shell (the shell mainly used in Plan 9); however, rc's path environment variable conventionally only contains the {{code|/bin}} and {{code|.}} directories and modifying the variable is discouraged, instead, adding additional commands should be done by binding several directories together as a single {{code|/bin}}.<ref name="rc_the_plan_9_shell">{{cite book |last1=Duff |first1=Tom |title=Rc — The Plan 9 Shell |url=http://doc.cat-v.org/plan_9/4th_edition/papers/rc|section=18|work=Plan 9, 4th edition}} ([https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf PDF]);</ref><ref name= "distributed-system" /> Unlike in Plan 9, the path environment variable of Unix shells should be set to include the additional directories whose executable files need to be added as commands.

Furthermore, the kernel can keep separate mount tables for each process,<ref name="HerbertJones2004"/> and can thus provide each process with its own file system [[namespace]]. Processes' namespaces can be constructed independently, and the user may work simultaneously with programs that have heterogeneous namespaces.<ref name = "use-of-namespaces" /> Namespaces may be used to create an isolated environment similar to [[chroot]], but in a more secure way.<ref name="unix-spirit-set-free" />

Plan 9's union directory architecture inspired [[4.4BSD]] and [[Linux]] [[union mount|union file system]] implementations,{{r|valerie-aurora}} although the developers of the BSD union mounting facility found the non-recursive merging of directories in Plan 9 "too restrictive for general purpose use".{{r|4.4bsd}}
{{clear}}

=== Special virtual filesystem ===

==== /proc ====
[[File:Plan 9 from Bell Labs (process management).png|thumb|right|Listing processes with [[ls|list contents of directory (ls, lc) command]]<ref name="unix-plan9-command-translation" /> in {{mono|/proc}}]]
{{Main |procfs}}
Instead of having system calls specifically for [[process management (computing)|process management]], Plan 9 provides the {{mono|/proc}} file system. Each [[Process (computing)|process]] appears as a directory containing information and control files which can be manipulated by the ordinary file IO system calls.<ref name = "design-paper" />

The file system approach allows Plan 9 processes to be managed with simple file management tools such as [[ls]] and [[cat (Unix)|cat]]; however, the processes cannot be copied and moved as files.<ref name="design-paper" />

==== /net ====
Plan 9 does not have specialised system calls or [[ioctl]]s for accessing the networking stack or networking hardware. Instead, the {{mono|/net}} file system is used. Network connections are controlled by reading and writing control messages to control files.  Sub-directories such as {{mono|/net/tcp}} and {{mono|/net/udp}} are used as an interface to their respective protocols.<ref name="design-paper" />

=== Unicode ===
{{Further|UTF-8|Comparison of Unicode encodings}}
To reduce the complexity of managing [[character encoding]]s, Plan 9 uses [[Unicode]] throughout the system. The initial Unicode implementation was [[ISO/IEC 10646-1:1993]]. [[Ken Thompson (computer programmer)|Ken Thompson]] invented UTF-8, which became the [[native (computing)|native]] encoding in Plan 9. The entire system was converted to general use in 1992.<ref name= "utf8" /> UTF-8 preserves backwards compatibility with traditional [[null-terminated string]]s, enabling more reliable information processing and the chaining of multilingual string data with [[Unix pipe]]s between multiple processes.  Using a single UTF-8 encoding with characters for all cultures and regions eliminates the need for switching between code sets.<ref name="Lunde1999" />

=== Combining the design concepts ===
Though interesting on their own, the design concepts of Plan 9 were supposed to be most useful when combined. For example, to implement a [[network address translation]] (NAT) server, a union directory can be created, overlaying the [[router (computing)|router]]'s {{mono|/net}} directory tree with its own {{mono|/net}}. Similarly, a [[virtual private network]] (VPN) can be implemented by overlaying in a union directory a {{mono|/net}} hierarchy from a remote [[gateway (telecommunications)|gateway]], using secured 9P over the public Internet. A union directory with the {{mono|/net}} hierarchy and filters can be used to [[sandbox (computer security)|sandbox]] an untrusted application or to implement a [[Firewall (computing)|firewall]].<ref name="unix-spirit-set-free" /> In the same manner, a distributed computing network can be composed with a union directory of {{mono|/proc}} hierarchies from remote hosts, which allows interacting with them as if they are local.

When used together, these features allow for assembling a complex distributed computing environment by reusing the existing hierarchical name system.<ref name="design-paper" />