1 .HTML "The Use of Name Spaces in Plan 9
3 The Use of Name Spaces in Plan 9
17 Operating Systems Review,
19 Vol. 27, #2, April 1993, pp. 72-76
22 Proceedings of the 5th ACM SIGOPS European Workshop,
24 Mont Saint-Michel, 1992, Paper nº 34).
26 Plan 9 is a distributed system built at the Computing Sciences Research
27 Center of AT&T Bell Laboratories (now Lucent Technologies, Bell Labs) over the last few years.
28 Its goal is to provide a production-quality system for software
29 development and general computation using heterogeneous hardware
30 and minimal software. A Plan 9 system comprises CPU and file
31 servers in a central location connected together by fast networks.
32 Slower networks fan out to workstation-class machines that serve as
33 user terminals. Plan 9 argues that given a few carefully
34 implemented abstractions
36 produce a small operating system that provides support for the largest systems
37 on a variety of architectures and networks. The foundations of the system are
38 built on two ideas: a per-process name space and a simple message-oriented
42 The operating system for the CPU servers and terminals is
43 structured as a traditional kernel: a single compiled image
44 containing code for resource management, process control,
46 virtual memory, and I/O. Because the file server is a separate
47 machine, the file system is not compiled in, although the management
48 of the name space, a per-process attribute, is.
49 The entire kernel for the multiprocessor SGI Power Series machine
51 the largest part of which is code for four networks including the
52 Ethernet with the Internet protocol suite.
53 Fewer than 1500 lines are machine-specific, and a
54 functional kernel with minimal I/O can be put together from
55 source files totaling 6000 lines. [Pike90]
57 The system is relatively small for several reasons.
58 First, it is all new: it has not had time to accrete as many fixes
59 and features as other systems.
60 Also, other than the network protocol, it adheres to no
61 external interface; in particular, it is not Unix-compatible.
62 Economy stems from careful selection of services and interfaces.
63 Finally, wherever possible the system is built around
65 every resource in the system, either local or remote,
66 is represented by a hierarchical file system; and
68 assembles a private view of the system by constructing a file
72 that connects these resources. [Needham]
76 All resources in Plan 9 look like file systems.
77 That does not mean that they are repositories for
78 permanent files on disk, but that the interface to them
79 is file-oriented: finding files (resources) in a hierarchical
80 name tree, attaching to them by name, and accessing their contents
81 by read and write calls.
82 There are dozens of file system types in Plan 9, but only a few
83 represent traditional files.
84 At this level of abstraction, files in Plan 9 are similar
85 to objects, except that files are already provided with naming,
86 access, and protection methods that must be created afresh for
87 objects. Object-oriented readers may approach the rest of this
88 paper as a study in how to make objects look like files.
90 The interface to file systems is defined by a protocol, called 9P,
91 analogous but not very similar to the NFS protocol.
92 The protocol talks about files, not blocks; given a connection to the root
93 directory of a file server,
94 the 9P messages navigate the file hierarchy, open files for I/O,
95 and read or write arbitrary bytes in the files.
96 9P contains 17 message types: three for
98 authenticating a connection and fourteen for manipulating objects.
99 The messages are generated by the kernel in response to user- or
100 kernel-level I/O requests.
101 Here is a quick tour of the major message types.
106 messages authenticate a connection, established by means outside 9P,
107 and validate its user.
108 The result is an authenticated
110 that points to the root of the
114 message makes a new channel identical to an existing channel,
115 which may be moved to a file on the server using a
117 message to descend each level in the hierarchy.
122 messages read and write the attributes of the file pointed to by a channel.
125 message prepares a channel for subsequent
129 messages to access the contents of the file, while
133 perform, on the files, the actions implied by their names.
136 message discards a channel without affecting the file.
137 None of the 9P messages consider caching; file caches are provided,
138 when needed, either within the server (centralized caching)
139 or by implementing the cache as a transparent file system between the
140 client and the 9P connection to the server (client caching).
142 For efficiency, the connection to local
143 kernel-resident file systems, misleadingly called
145 is by regular rather than remote procedure calls.
146 The procedures map one-to-one with 9P message types.
147 Locally each channel has an associated data structure
148 that holds a type field used to index
149 a table of procedure calls, one set per file system type,
150 analogous to selecting the method set for an object.
151 One kernel-resident file system, the
155 translates the local 9P procedure calls into RPC messages to
156 remote services over a separately provided transport protocol
157 such as TCP or IL, a new reliable datagram protocol, or over a pipe to
159 Write and read calls transmit the messages over the transport layer.
160 The mount device is the sole bridge between the procedural
161 interface seen by user programs and remote and user-level services.
162 It does all associated marshaling, buffer
163 management, and multiplexing and is
164 the only integral RPC mechanism in Plan 9.
165 The mount device is in effect a proxy object.
166 There is no RPC stub compiler; instead the mount driver and
167 all servers just share a library that packs and unpacks 9P messages.
171 One file system type serves
172 permanent files from the main file server,
173 a stand-alone multiprocessor system with a
175 optical WORM jukebox that holds the data, fronted by a two-level
176 block cache comprising 7 gigabytes of
177 magnetic disk and 128 megabytes of RAM.
178 Clients connect to the file server using any of a variety of
179 networks and protocols and access files using 9P.
180 The file server runs a distinct operating system and has no
181 support for user processes; other than a restricted set of commands
182 available on the console, all it does is answer 9P messages from clients.
184 Once a day, at 5:00 AM,
185 the file server sweeps through the cache blocks and marks dirty blocks
187 It creates a copy of the root directory
188 and labels it with the current date, for example
190 It then starts a background process to copy the dirty blocks to the WORM.
191 The result is that the server retains an image of the file system as it was
193 The set of old root directories is accessible using 9P, so a client
194 may examine backup files using ordinary commands.
195 Several advantages stem from having the backup service implemented
196 as a plain file system.
197 Most obviously, ordinary commands can access them.
198 For example, to see when a bug was fixed
200 grep 'mouse bug fix' 1995/*/sys/src/cmd/8½/file.c
202 The owner, access times, permissions, and other properties of the
203 files are also backed up.
204 Because it is a file system, the backup
205 still has protections;
206 it is not possible to subvert security by looking at the backup.
208 The file server is only one type of file system.
209 A number of unusual services are provided within the kernel as
211 These services are not limited to I/O devices such
212 as disks. They include network devices and their associated protocols,
213 the bitmap display and mouse,
214 a representation of processes similar to
216 [Killian], the name/value pairs that form the `environment'
217 passed to a new process, profiling services,
219 Each of these is represented as a file system \(em
220 directories containing sets of files \(em
221 but the constituent files do not represent permanent storage on disk.
222 Instead, they are closer in properties to UNIX device files.
226 device contains the file
228 similar to the UNIX file
232 appends to the console typescript; when read,
233 it returns characters typed on the keyboard.
234 Other files in the console device include
236 the number of seconds since the epoch,
238 the computation time used by the process reading the device,
240 the process id of the process reading the device, and
242 the login name of the user accessing the device.
243 All these files contain text, not binary numbers,
244 so their use is free of byte-order problems.
245 Their contents are synthesized on demand when read; when written,
246 they cause modifications to kernel data structures.
250 device contains one directory per live local process, named by its numeric
255 Each directory contains a set of files that access the process.
256 For example, in each directory the file
258 is an image of the virtual memory of the process that may be read or
259 written for debugging.
262 file is a sort of link to the file from which the process was executed;
263 it may be opened to read the symbol tables for the process.
266 file may be written textual messages such as
270 to control the execution of the process.
273 file contains a fixed-format line of text containing information about
274 the process: its name, owner, state, and so on.
275 Text strings written to the
277 file are delivered to the process as
279 analogous to UNIX signals.
280 By providing these services as textual I/O on files rather
281 than as system calls (such as
283 or special-purpose operations (such as
285 the Plan 9 process device simplifies the implementation of
286 debuggers and related programs.
287 For example, the command
291 is a crude form of the
295 merely reformats the data so obtained.
299 device contains three files,
304 that provide an interface to the local bitmap display (if any) and pointing device.
307 file returns a fixed-format record containing
308 1 byte of button state and 4 bytes each of
312 position of the mouse.
313 If the mouse has not moved since the file was last read, a subsequent read will
317 file contains a memory image of the contents of the display;
320 file provides a procedural interface.
321 Calls to the graphics library are translated into messages that are written
324 file to perform bitmap graphics operations. (This is essentially a nested
327 The various services being used by a process are gathered together into the
332 a single rooted hierarchy of file names.
333 When a process forks, the child process shares the name space with the parent.
334 Several system calls manipulate name spaces.
335 Given a file descriptor
337 that holds an open communications channel to a service,
340 mount(int fd, char *old, int flags)
342 authenticates the user and attaches the file tree of the service to
343 the directory named by
347 specify how the tree is to be attached to
349 replacing the current contents or appearing before or after the
350 current contents of the directory.
351 A directory with several services mounted is called a
353 directory and is searched in the specified order.
356 bind(char *new, char *old, int flags)
358 takes the portion of the existing name space visible at
360 either a file or a directory, and makes it also visible at
364 bind("1995/0301/sys/include", "/sys/include", REPLACE)
366 causes the directory of include files to be overlaid with its
367 contents from the dump on March first.
369 A process is created by the
371 system call, which takes as argument a bit vector defining which
372 attributes of the process are to be shared between parent
373 and child instead of copied.
374 One of the attributes is the name space: when shared, changes
375 made by either process are visible in the other; when copied,
376 changes are independent.
378 Although there is no global name space,
379 for a process to function sensibly the local name spaces must adhere
380 to global conventions.
381 Nonetheless, the use of local name spaces is critical to the system.
382 Both these ideas are illustrated by the use of the name space to
383 handle heterogeneity.
384 The binaries for a given architecture are contained in a directory
385 named by the architecture, for example
387 in use, that directory is bound to the conventional location
389 Programs such as shell scripts need not know the CPU type they are
390 executing on to find binaries to run.
391 A directory of private binaries
392 is usually unioned with
398 and special-purpose idea of the
400 variable, which is not used in the Plan 9 shell.)
401 Local bindings are also helpful for debugging, for example by binding
402 an old library to the standard place and linking a program to see
403 if recent changes to the library are responsible for a bug in the program.
407 [Pike91], is a server for files such as
411 Each client sees a distinct copy of these files in its local
412 name space: there are many instances of
416 to the local name space of a window.
419 implements services using
420 local name spaces plus the use
421 of I/O to conventionally named files.
422 Each client just connects its standard input, output, and error files
425 with analogous operations to access bitmap graphics.
426 Compare this to the implementation of
428 on UNIX, which is done by special code in the kernel
429 that overloads the file, when opened,
430 with the standard input or output of the process.
431 Special arrangement must be made by a UNIX window system for
433 to behave as expected;
435 instead uses the provision of the corresponding file as its
436 central idea, which to succeed depends critically on local name spaces.
440 provides its clients is exactly the environment under which it is implemented:
441 a conventional set of files in
443 This permits the window system to be run recursively in one of its own
444 windows, which is handy for debugging.
445 It also means that if the files are exported to another machine,
446 as described below, the window system or client applications may be
447 run transparently on remote machines, even ones without graphics hardware.
448 This mechanism is used for Plan 9's implementation of the X window
449 system: X is run as a client of
451 often on a remote machine with lots of memory.
452 In this configuration, using Ethernet to connect
453 MIPS machines, we measure only a 10% degradation in graphics
454 performance relative to running X on
455 a bare Plan 9 machine.
457 An unusual application of these ideas is a statistics-gathering
458 file system implemented by a command called
460 The command encapsulates a process in a local name space, monitoring 9P
461 requests from the process to the outside world \(em the name space in which
463 is itself running. When the command completes,
465 reports usage and performance figures for file activity.
470 can be used to discover how much I/O the window system
471 does to the bitmap device, font files, and so on.
475 command connects a piece of name space from a remote system
476 to the local name space.
477 Its implementation is to dial the remote machine and start
478 a process there that serves the remote name space using 9P.
481 to attach the connection to the name space and finally dies;
482 the remote process continues to serve the files.
483 One use is to access devices not available
484 locally. For example, to write a floppy one may say
486 import lab.pc /a: /n/dos
491 connects the file tree from
495 (which must support 9P) to the local directory
499 can be written to the floppy just by copying it across.
501 Another application is remote debugging:
505 makes the process file system on machine
507 available locally; commands such as
511 processes instead of the local ones.
512 The debugger may then look at a remote process:
514 db /proc/27/text /proc/27/mem
516 allows breakpoint debugging of the remote process.
519 infers the CPU type of the process from the executable header on
520 the text file, it supports
521 cross-architecture debugging, too.
524 to handle issues of byte order and floating point; it is possible to
525 breakpoint debug a big-endian MIPS process from a little-endian i386.
527 Network interfaces are also implemented as file systems [Presotto].
530 is a directory somewhat like
532 it contains a set of numbered directories, one per connection,
533 each of which contains files to control and communicate on the connection.
534 A process allocates a new connection by accessing
536 which evaluates to the directory of an unused connection.
537 To make a call, the process writes a textual message such as
539 .CW 135.104.53.2!512'
542 file and then reads and writes the
547 service can be implemented in a few of lines of shell code.
549 This structure makes network gatewaying easy to provide.
550 We have machines with Datakit interfaces but no Internet interface.
551 On such a machine one may type
554 telnet tcp!ai.mit.edu
558 uses Datakit to pull in the TCP interface from
560 which can then be used directly; the
562 notation is necessary because we routinely use multiple networks
563 and protocols on Plan 9\(emit identifies the network in which
567 In practice we do not use
571 between Plan 9 machines. Instead a command called
573 in effect replaces the CPU in a window with that
574 on another machine, typically a fast multiprocessor CPU server.
575 The implementation is to recreate the
576 name space on the remote machine, using the equivalent of
578 to connect pieces of the terminal's name space to that of
579 the process (shell) on the CPU server, making the terminal
580 a file server for the CPU.
581 CPU-local devices such as fast file system connections
582 are still local; only terminal-resident devices are
584 The result is unlike UNIX
586 which moves into a distinct name space on the remote machine,
589 which keeps the name space the same but forces processes to execute
593 may change because of a change in CPU architecture, and
594 the networks involved may be different because of differing hardware,
595 but the effect feels like simply speeding up the processor in the
600 These examples illustrate how the ideas of representing resources
601 as file systems and per-process name spaces can be used to solve
602 problems often left to more exotic mechanisms.
603 Nonetheless there are some operations in Plan 9 that are not
604 mapped into file I/O.
605 An example is process creation.
606 We could imagine a message to a control file in
608 that creates a process, but the details of
609 constructing the environment of the new process \(em its open files,
610 name space, memory image, etc. \(em are too intricate to
611 be described easily in a simple I/O operation.
612 Therefore new processes on Plan 9 are created by fairly conventional
618 is used only to represent and control existing processes.
620 Plan 9 does not attempt to map network name spaces into the file
621 system name space, for several reasons.
622 The different addressing rules for various networks and protocols
623 cannot be mapped uniformly into a hierarchical file name space.
624 Even if they could be,
625 the various mechanisms to authenticate,
627 and control the connection would not map consistently into
628 operations on a file.
630 Shared memory is another resource not adequately represented by a
632 Plan 9 takes care to provide mechanisms
633 to allow groups of local processes to share and map memory.
635 by system calls rather than special files, however,
636 since a representation in the file system would imply that memory could
637 be imported from remote machines.
639 Despite these limitations, file systems and name spaces offer an effective
640 model around which to build a distributed system.
641 Used well, they can provide a uniform, familiar, transparent
642 interface to a diverse set of distributed resources.
643 They carry well-understood properties of access, protection,
645 The integration of devices into the hierarchical file system
646 was the best idea in UNIX.
647 Plan 9 pushes the concepts much further and shows that
648 file systems, when used inventively, have plenty of scope
649 for productive research.
653 [Killian] T. Killian, ``Processes as Files'', USENIX Summer Conf. Proc., Salt Lake City, 1984
655 [Needham] R. Needham, ``Names'', in
662 [Pike90] R. Pike, D. Presotto, K. Thompson, H. Trickey,
663 ``Plan 9 from Bell Labs'',
664 UKUUG Proc. of the Summer 1990 Conf.,
668 [Presotto] D. Presotto, ``Multiprocessor Streams for Plan 9'',
669 UKUUG Proc. of the Summer 1990 Conf.,
673 [Pike91] Pike, R., ``8.5, The Plan 9 Window System'', USENIX Summer
674 Conf. Proc., Nashville, 1991
projects / plan9front.git / blob