next up previous contents
Next: 6.2.1 Inferno Up: 6. Related Work Previous: 6.1.2 Conclusions

6.2 Plan 9

Plan 9 was developed at Bell Labs in the late 1980's [Pike90,Pike91,Presotto93]. The Plan 9 approach to file system extension is similar to that of Unix.

The Plan 9 mount system call provides a file descriptor that can be a user process or remote file server. After a successful mount, operations below the mount point are sent to the file server. Plan 9's equivalent of the vnode interface (called 9P) comprises the following operations:

nop: The NULL (``ping'') call. It could be used to synchronize a file descriptor between two entities.

session: Initialize a connection between a client and a server. This is similar to the VFS mount operation.

attach: Connect a user to a file server. Returns a new file descriptor for the root of the file system. Similar to the ``get root'' vnode operation.

auth: Authenticate a 9P connection.

clone: Duplicate an existing file descriptor between a user and a file server so that a new copy could be operated upon separately to provide user-specific name space.

walk: Traverse a file server (similar to lookup).

clwalk: Perform a clone operation followed by a walk operation. This one is an optimization of this common sequence of operations, for use with low-speed network connections.

create: Create a new file.

open: Prepare a file descriptor before read or write operations.

read: Read from a file descriptor.

write: Write to a file represented by a file descriptor.

clunk: Close a file descriptor (without affecting the file).

remove: Delete an existing file.

stat: Read the attributes of a file

wstat: Write attributes to a file.

flush: Abort a message and discard all remaining replies to it from a server.

error: Return an error code.

These operation messages are sent to a file server by the Plan 9 kernel in response to client requests, much the same way as user-level NFS servers behave.

My impression is that Plan 9 and 9P provide little benefit over what can be done with the vnode interface and a user level NFS server. Certainly, there is no major novelty in Plan 9 likes the translation concept of the HURD. Support for writing Plan 9 file servers is limited, and the functionality they can provide is not as well thought out as the HURD's. The HURD therefore provides a more flexible file service extension mechanism.

Changing FiST's language and translator to generate Plan 9 file system code would be no more difficult than doing it for the HURD.

next up previous contents
Next: 6.2.1 Inferno Up: 6. Related Work Previous: 6.1.2 Conclusions
Erez Zadok