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:

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

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

3.
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.

4.
auth: Authenticate a 9P connection.

5.
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.

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

7.
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.

8.
create: Create a new file.

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

10.
read: Read from a file descriptor.

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

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

13.
remove: Delete an existing file.

14.
stat: Read the attributes of a file

15.
wstat: Write attributes to a file.

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

17.
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
1999-12-07