Import sources from 2011-03-30 iso image - sys/man

13 files changed, 2003 insertions, 0 deletions

diff --git a/sys/man/5/0intro b/sys/man/5/0intro
new file mode 100755
index 000000000..378393e56
--- /dev/null
+++ b/sys/man/5/0intro
@@ -0,0 +1,607 @@
+.TH INTRO 5 
+.SH NAME
+intro \- introduction to the Plan 9 File Protocol, 9P
+.SH SYNOPSIS
+.B #include <fcall.h>
+.SH DESCRIPTION
+A Plan 9
+.I server
+is an agent that provides one or more hierarchical file systems
+\(em file trees \(em
+that may be accessed by Plan 9 processes.
+A server responds to requests by
+.I clients
+to navigate the hierarchy,
+and to create, remove, read, and write files.
+The prototypical server is a separate machine that stores
+large numbers of user files on permanent media;
+such a machine is called, somewhat confusingly, a
+.I file
+.IR server .
+Another possibility for a server is to synthesize
+files on demand, perhaps based on information on data structures
+inside the kernel; the
+.IR proc (3)
+.I kernel device
+is a part of the Plan 9 kernel that does this.
+User programs can also act as servers.
+.PP
+A
+.I connection
+to a server is a bidirectional communication path from the client to the server.
+There may be a single client or
+multiple clients sharing the same connection.
+A server's file tree is attached to a process
+group's name space by
+.IR bind (2)
+and
+.I mount
+calls;
+see
+.IR intro (2).
+Processes in the group are then clients
+of the server:
+system calls operating on files are translated into requests
+and responses transmitted on the connection to the appropriate service.
+.PP
+The
+.IR "Plan 9 File Protocol" ,
+9P, is used for messages between
+.I clients
+and
+.IR servers .
+A client transmits
+.I requests
+.RI ( T-messages )
+to a server, which
+subsequently returns
+.I replies
+.RI ( R-messages )
+to the client.
+The combined acts of transmitting (receiving) a request of a particular type,
+and receiving (transmitting)
+its reply is called a
+.I transaction
+of that type.
+.PP
+Each message consists of a sequence of bytes.
+Two-, four-, and eight-byte fields hold unsigned
+integers represented in little-endian order
+(least significant byte first).
+Data items of larger or variable lengths are represented
+by a two-byte field specifying a count,
+.IR n ,
+followed by
+.I n
+bytes of data.
+Text strings are represented this way,
+with the text itself stored as a UTF-8
+encoded sequence of Unicode characters (see
+.IR utf (6)).
+Text strings in 9P messages are not
+.SM NUL\c
+-terminated:
+.I n
+counts the bytes of UTF-8 data, which include no final zero byte.
+The
+.SM NUL
+character is illegal in all text strings in 9P, and is therefore
+excluded from file names, user names, and so on.
+.PP
+Each 9P message begins with a four-byte size field
+specifying the length in bytes of the complete message including
+the four bytes of the size field itself.
+The next byte is the message type, one of the constants
+in the enumeration in the include file
+.BR <fcall.h> .
+The next two bytes are an identifying
+.IR tag ,
+described below.
+The remaining bytes are parameters of different sizes.
+In the message descriptions, the number of bytes in a field
+is given in brackets after the field name.
+The notation
+.IR parameter [ n ]
+where
+.I n
+is not a constant represents a variable-length parameter:
+.IR n [2]
+followed by
+.I n
+bytes of data forming the
+.IR parameter .
+The notation
+.IR string [ s ]
+(using a literal
+.I s
+character)
+is shorthand for
+.IR s [2]
+followed by
+.I s
+bytes of UTF-8 text.
+(Systems may choose to reduce the set of legal characters
+to reduce syntactic problems,
+for example to remove slashes from name components,
+but the protocol has no such restriction.
+Plan 9 names may contain any printable character (that is, any character
+outside hexadecimal 00-1F and 80-9F)
+except slash.)
+Messages are transported in byte form to allow for machine independence;
+.IR fcall (2)
+describes routines that convert to and from this form into a machine-dependent
+C structure.
+.SH MESSAGES
+.ta \w'\fLTsession 'u
+.IP
+.ne 2v
+.IR size [4]
+.B Tversion
+.IR tag [2]
+.IR msize [4]
+.IR version [ s ]
+.br
+.IR size [4]
+.B Rversion
+.IR tag [2]
+.IR msize [4]
+.IR version [ s ]
+.IP
+.ne 2v
+.IR size [4]
+.B Tauth
+.IR tag [2]
+.IR afid [4]
+.IR uname [ s ]
+.IR aname [ s ]
+.br
+.br
+.IR size [4]
+.B Rauth
+.IR tag [2]
+.IR aqid [13]
+.IP
+.ne 2v
+.IR size [4]
+.B Rerror
+.IR tag [2]
+.IR ename [ s ]
+.IP
+.ne 2v
+.IR size [4]
+.B Tflush
+.IR tag [2]
+.IR oldtag [2]
+.br
+.IR size [4]
+.B Rflush
+.IR tag [2]
+.IP
+.ne 2v
+.IR size [4]
+.B Tattach
+.IR tag [2]
+.IR fid [4]
+.IR afid [4]
+.IR uname [ s ]
+.IR aname [ s ]
+.br
+.IR size [4]
+.B Rattach
+.IR tag [2]
+.IR qid [13]
+.IP
+.ne 2v
+.IR size [4]
+.B Twalk
+.IR tag [2]
+.IR fid [4]
+.IR newfid [4]
+.IR nwname [2]
+.IR nwname *( wname [ s ])
+.br
+.IR size [4]
+.B Rwalk
+.IR tag [2]
+.IR nwqid [2]
+.IR nwqid *( wqid [13])
+.IP
+.ne 2v
+.IR size [4]
+.B Topen
+.IR tag [2]
+.IR fid [4]
+.IR mode [1]
+.br
+.IR size [4]
+.B Ropen
+.IR tag [2]
+.IR qid [13]
+.IR iounit [4]
+.IP
+.ne 2v
+.IR size [4]
+.B Tcreate
+.IR tag [2]
+.IR fid [4]
+.IR name [ s ]
+.IR perm [4]
+.IR mode [1]
+.br
+.IR size [4]
+.B Rcreate
+.IR tag [2]
+.IR qid [13]
+.IR iounit [4]
+.IP
+.ne 2v
+.IR size [4]
+.B Tread
+.IR tag [2]
+.IR fid [4]
+.IR offset [8]
+.IR count [4]
+.br
+.IR size [4]
+.B Rread
+.IR tag [2]
+.IR count [4]
+.IR data [ count ]
+.IP
+.ne 2v
+.IR size [4]
+.B Twrite
+.IR tag [2]
+.IR fid [4]
+.IR offset [8]
+.IR count [4]
+.IR data [ count ]
+.br
+.IR size [4]
+.B Rwrite
+.IR tag [2]
+.IR count [4]
+.IP
+.ne 2v
+.IR size [4]
+.B Tclunk
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rclunk
+.IR tag [2]
+.IP
+.ne 2v
+.IR size [4]
+.B Tremove
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rremove
+.IR tag [2]
+.IP
+.ne 2v
+.IR size [4]
+.B Tstat
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rstat
+.IR tag [2]
+.IR stat [ n ]
+.IP
+.ne 2v
+.IR size [4]
+.B Twstat
+.IR tag [2]
+.IR fid [4]
+.IR stat [ n ]
+.br
+.IR size [4]
+.B Rwstat
+.IR tag [2]
+.PP
+Each T-message has a
+.I tag
+field, chosen and used by the client to identify the message.
+The reply to the message will have the same tag.
+Clients must arrange that no two outstanding messages
+on the same connection have the same tag.
+An exception is the tag
+.BR NOTAG ,
+defined as
+.B (ushort)~0
+in
+.BR <fcall.h> :
+the client can use it, when establishing a connection,
+to
+override tag matching in
+.B version
+messages.
+.PP
+The type of an R-message will either be one greater than the type
+of the corresponding T-message or
+.BR Rerror ,
+indicating that the request failed.
+In the latter case, the
+.I ename
+field contains a string describing the reason for failure.
+.PP
+The
+.B version
+message identifies the version of the protocol and indicates
+the maximum message size the system is prepared to handle.
+It also initializes the connection and
+aborts all outstanding I/O on the connection.
+The set of messages between
+.B version
+requests is called a
+.IR session .
+.PP
+Most T-messages contain a
+.IR fid ,
+a 32-bit unsigned integer that the client uses to identify
+a ``current file'' on the server.
+Fids are somewhat like file descriptors in a user process,
+but they are not restricted to files open for I/O:
+directories being examined, files being accessed by
+.IR stat (2)
+calls, and so on \(em all files being manipulated by the operating
+system \(em are identified by fids.
+Fids are chosen by the client.
+All requests on a connection share the same fid space;
+when several clients share a connection,
+the agent managing the sharing must arrange
+that no two clients choose the same fid.
+.PP
+The fid supplied in an
+.B attach
+message
+will be taken by the server to refer to the root of the served file tree.
+The
+.B attach
+identifies the user
+to the server and may specify a particular file tree served
+by the server (for those that supply more than one).
+.PP
+Permission to attach to the service is proven by providing a special fid, called
+.BR afid ,
+in the
+.B attach
+message.  This
+.B afid
+is established by exchanging
+.B auth
+messages and subsequently manipulated using
+.B read
+and
+.B write
+messages to exchange authentication information not defined explicitly by 9P.
+Once the authentication protocol is complete, the
+.B afid
+is presented in the
+.B attach
+to permit the user to access the service.
+.PP
+A
+.B walk
+message causes the server to change the current file associated
+with a fid to be a file in the directory that is the old current file, or one of
+its subdirectories.
+.B Walk
+returns a new fid that refers to the resulting file.
+Usually, a client maintains a fid for the root,
+and navigates by
+.B walks
+from the root fid.
+.PP
+A client can send multiple T-messages without waiting for the corresponding
+R-messages, but all outstanding T-messages must specify different tags.
+The server may delay the response to a request
+and respond to later ones;
+this is sometimes necessary, for example when the client reads
+from a file that the server synthesizes from external events
+such as keyboard characters.
+.PP
+Replies (R-messages) to
+.BR auth ,
+.BR attach ,
+.BR walk ,
+.BR open ,
+and
+.B create
+requests convey a
+.I qid
+field back to the client.
+The qid represents the server's unique identification for the
+file being accessed:
+two files on the same server hierarchy are the same if and only if their qids
+are the same.
+(The client may have multiple fids pointing to a single file on a server
+and hence having a single qid.)
+The thirteen-byte qid fields hold a one-byte type,
+specifying whether the file is a directory, append-only file, etc.,
+and two unsigned integers:
+first the four-byte qid
+.IR version ,
+then the eight-byte qid
+.IR path .
+The path is an integer unique among all files in the hierarchy.
+If a file is deleted and recreated with the
+same name in the same directory, the old and new path components of the qids
+should be different.
+The version is a version number for a file;
+typically, it is incremented every time the file is modified.
+.PP
+An existing file can be
+.BR opened ,
+or a new file may be
+.B created
+in the current (directory) file.
+I/O of a given number of bytes
+at a given offset
+on an open file is done by
+.B read
+and
+.BR write .
+.PP
+A client should
+.B clunk
+any fid that is no longer needed.
+The
+.B remove
+transaction deletes files.
+.PP
+The
+.B stat
+transaction retrieves information about the file.
+The
+.I stat
+field in the reply includes the file's
+name,
+access permissions (read, write and execute for owner, group and public),
+access and modification times, and
+owner and group identifications
+(see
+.IR stat (2)).
+The owner and group identifications are textual names.
+The
+.B wstat
+transaction allows some of a file's properties
+to be changed.
+.PP
+A request can be aborted with a
+flush
+request.
+When a server receives a
+.BR Tflush ,
+it should not reply to the message with tag
+.I oldtag
+(unless it has already replied),
+and it should immediately send an
+.BR Rflush .
+The client must wait
+until it gets the
+.B Rflush
+(even if the reply to the original message arrives in the interim),
+at which point
+.I oldtag
+may be reused.
+.PP
+Because the message size is negotiable and some elements of the
+protocol are variable length, it is possible (although unlikely) to have
+a situation where a valid message is too large to fit within the negotiated size.
+For example, a very long file name may cause a
+.B Rstat
+of the file or
+.B Rread
+of its directory entry to be too large to send.
+In most such cases, the server should generate an error rather than
+modify the data to fit, such as by truncating the file name.
+The exception is that a long error string in an
+.B Rerror
+message should be truncated if necessary, since the string is only
+advisory and in some sense arbitrary.
+.PP
+Most programs do not see the 9P protocol directly; instead calls to library
+routines that access files are
+translated by the mount driver,
+.IR mnt (3),
+into 9P messages.
+.SH DIRECTORIES
+Directories are created by
+.B create
+with
+.B DMDIR
+set in the permissions argument (see
+.IR stat (5)).
+The members of a directory can be found with
+.IR read (5).
+All directories must support
+.B walks
+to the directory
+.B ..
+(dot-dot)
+meaning parent directory, although by convention directories
+contain no explicit entry for
+.B ..
+or
+.B .
+(dot).
+The parent of the root directory of a server's tree is itself.
+.SH "ACCESS PERMISSIONS"
+Each file server maintains a set of user and group names.
+Each user can be a member of any number of groups.
+Each group has a
+.I group leader
+who has special privileges (see
+.IR stat (5)
+and
+.IR users (6)).
+Every file request has an implicit user id (copied from the original
+.BR attach )
+and an implicit set of groups (every group of which the user is a member).
+.PP
+Each file has an associated
+.I owner
+and
+.I group
+id and
+three sets of permissions:
+those of the owner, those of the group, and those of ``other'' users.
+When the owner attempts to do something to a file, the owner, group,
+and other permissions are consulted, and if any of them grant
+the requested permission, the operation is allowed.
+For someone who is not the owner, but is a member of the file's group,
+the group and other permissions are consulted.
+For everyone else, the other permissions are used.
+Each set of permissions says whether reading is allowed,
+whether writing is allowed, and whether executing is allowed.
+A
+.B walk
+in a directory is regarded as executing the directory,
+not reading it.
+Permissions are kept in the low-order bits of the file
+.IR mode :
+owner read/write/execute permission represented as 1 in bits 8, 7, and 6
+respectively (using 0 to number the low order).
+The group permissions are in bits 5, 4, and 3,
+and the other permissions are in bits 2, 1, and 0.
+.PP
+The file
+.I mode
+contains some additional attributes besides the permissions.
+If bit 31
+.RB ( DMDIR )
+is set, the file is a directory;
+if bit 30
+.RB ( DMAPPEND )
+is set, the file is append-only (offset is ignored in writes);
+if bit 29
+.RB ( DMEXCL )
+is set, the file is exclusive-use (only one client may have it
+open at a time);
+if bit 27
+.RB ( DMAUTH )
+is set, the file is an authentication file established by
+.B auth
+messages;
+if bit 26
+.RB ( DMTMP )
+is set, the contents of the file (or directory) are not included in nightly archives.
+(Bit 28 is skipped for historical reasons.)
+These bits are reproduced, from the top bit down, in the type byte of the Qid:
+.BR QTDIR ,
+.BR QTAPPEND ,
+.BR QTEXCL ,
+(skipping one bit)
+.BR QTAUTH ,
+and
+.BR QTTMP .
+The name
+.BR QTFILE ,
+defined to be zero,
+identifies the value of the type for a plain file.
diff --git a/sys/man/5/INDEX b/sys/man/5/INDEX
new file mode 100755
index 000000000..a3b62ae88
--- /dev/null
+++ b/sys/man/5/INDEX
@@ -0,0 +1,16 @@
+0intro 0intro
+intro 0intro
+attach attach
+auth attach
+clunk clunk
+error error
+flush flush
+create open
+open open
+read read
+write read
+remove remove
+stat stat
+wstat stat
+version version
+walk walk
diff --git a/sys/man/5/INDEX.html b/sys/man/5/INDEX.html
new file mode 100755
index 000000000..35d30ca76
--- /dev/null
+++ b/sys/man/5/INDEX.html
@@ -0,0 +1,53 @@
+<HEAD>
+<TITLE>plan 9 man section 5</TITLE>
+</HEAD>
+<BODY>
+<B>[<A HREF="/sys/man/index.html">manual index</A>]</B>
+<H2>Plan 9 from Bell Labs - Section 5 - Plan 9 File Protocol, 9P</H2>
+<HR>
+<DL>
+<DT><A HREF="/magic/man2html/5/0intro">0intro</A>
+-  introduction to the Plan 9 File Protocol, 9P
+<DD><TT> intro</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/attach">attach</A>
+-  messages to establish a connection
+<DD><TT> attach, auth</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/clunk">clunk</A>
+-  forget about a fid
+<DD><TT> clunk</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/error">error</A>
+-  return an error
+<DD><TT> error</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/flush">flush</A>
+-  abort a message
+<DD><TT> flush</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/open">open</A>
+-  prepare a fid for I/O on an existing or new file
+<DD><TT> open, create</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/read">read</A>
+-  transfer data from and to a file
+<DD><TT> read, write</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/remove">remove</A>
+-  remove a file from a server
+<DD><TT> remove</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/stat">stat</A>
+-  inquire or change file attributes
+<DD><TT> stat, wstat</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/version">version</A>
+-  negotiate protocol version
+<DD><TT> version</TT>
+</DT>
+<DT><A HREF="/magic/man2html/5/walk">walk</A>
+-  descend a directory hierarchy
+<DD><TT> walk</TT>
+</DT>
+</DL>
diff --git a/sys/man/5/attach b/sys/man/5/attach
new file mode 100755
index 000000000..dd21c6b60
--- /dev/null
+++ b/sys/man/5/attach
@@ -0,0 +1,159 @@
+.TH ATTACH 5 
+.SH NAME
+attach, auth \- messages to establish a connection
+.SH SYNOPSIS
+.ta \w'\fLTauth 'u
+.IR size [4]
+.B Tauth
+.IR tag [2]
+.IR afid [4]
+.IR uname [ s ]
+.IR aname [ s ]
+.br
+.IR size [4]
+.B Rauth
+.IR tag [2]
+.IR aqid [13]
+.PP
+.IR size [4]
+.B Tattach
+.IR tag [2]
+.IR fid [4]
+.IR afid [4]
+.IR uname [ s ]
+.IR aname [ s ]
+.br
+.IR size [4]
+.B Rattach
+.IR tag [2]
+.IR qid [13]
+.SH DESCRIPTION
+.PP
+The
+.B attach
+message serves as a fresh introduction from a user on
+the client machine to the server.
+The message identifies the user
+.RI ( uname )
+and may select
+the file tree to access
+.RI ( aname ).
+The
+.I afid
+argument specifies a fid previously established by an
+.B auth
+message, as described below.
+.PP
+As a result of the
+.B attach
+transaction, the client will have a connection to the root
+directory of the desired file tree,
+represented by
+.IR fid .
+An error is returned if
+.I fid
+is already in use.
+The server's idea of the root of the file tree is represented by the returned
+.IR qid .
+.PP
+If the client does not wish to authenticate the connection, or knows that
+authentication is not required, the
+.I afid
+field in the
+.B attach
+message should be set to
+.BR NOFID ,
+defined as
+.B (u32int)~0
+in
+.BR <fcall.h> .
+If the client does wish to authenticate, it must acquire and validate an
+.I afid
+using an
+.B auth
+message before doing the
+.BR attach .
+.PP
+The
+.B auth
+message contains
+.IR afid ,
+a new fid to be established for authentication, and the
+.I uname
+and
+.I aname
+that will be those of the following
+.B attach
+message.
+If the server does not require authentication, it returns
+.B Rerror
+to the
+.B Tauth
+message.
+.PP
+If the server does require authentication, it returns
+.I aqid
+defining a file of type
+.B QTAUTH
+(see
+.IR intro (5))
+that may be read and written (using
+.B read
+and
+.B write
+messages in the usual way) to execute an authentication protocol.
+That protocol's definition is not part of 9P itself.
+.PP
+Once the protocol is complete, the same
+.I afid
+is presented in the
+.B attach
+message for the user, granting entry.
+The same validated
+.I afid
+may be used for multiple
+.B attach
+messages with the same
+.I uname
+and
+.IR aname .
+.SH ENTRY POINTS
+An
+.B attach
+transaction will be generated for kernel devices
+(see
+.IR intro (3))
+when a system call evaluates a file name
+beginning with
+.LR # .
+.IR Pipe (2)
+generates an attach on the kernel device
+.IR pipe (3).
+The
+.I mount
+system call
+(see
+.IR bind (2))
+generates an
+.B attach
+message to the remote file server.
+When the kernel boots, an
+.I attach
+is made to the root device,
+.IR root (3),
+and then an
+.B attach
+is made to the requested file server machine.
+.PP
+An
+.B auth
+transaction is generated by the
+.IR fauth (2)
+system call or by the first
+.B mount
+system call on an uninitialized connection.
+.SH SEE ALSO
+.IR auth (2),
+.IR fauth (2),
+.IR version (5),
+.IR authsrv (6)
diff --git a/sys/man/5/clunk b/sys/man/5/clunk
new file mode 100755
index 000000000..6256b3c46
--- /dev/null
+++ b/sys/man/5/clunk
@@ -0,0 +1,43 @@
+.TH CLUNK 5 
+.SH NAME
+clunk \- forget about a fid
+.SH SYNOPSIS
+.ta \w'\fLTclunk 'u
+.IR size [4]
+.B Tclunk
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rclunk
+.IR tag [2]
+.SH DESCRIPTION
+The
+.B clunk
+request informs the file server
+that the current file represented by
+.I fid 
+is no longer needed by the client.
+The actual file is not removed on the server unless the fid had been opened with
+.BR ORCLOSE .
+.PP
+Once a fid has been clunked,
+the same fid can be reused in a new
+.B walk
+or
+.B attach
+request.
+.PP
+Even if the
+.B clunk
+returns an error, the
+.I fid
+is no longer valid.
+.SH ENTRY POINTS
+A
+.B clunk
+message is generated by
+.I close
+and indirectly by other actions such as failed
+.I open
+calls.
diff --git a/sys/man/5/error b/sys/man/5/error
new file mode 100755
index 000000000..093108a6d
--- /dev/null
+++ b/sys/man/5/error
@@ -0,0 +1,28 @@
+.TH ERROR 5 
+.SH NAME
+error \- return an error
+.SH SYNOPSIS
+.ta \w'\fLRerror 'u
+.IR size [4]
+.B Rerror
+.IR tag [2]
+.IR ename [ s ]
+.SH DESCRIPTION
+The
+.B Rerror
+message
+(there is no
+.BR Terror )
+is used to return an error string
+describing the
+failure of a transaction.
+It replaces the corresponding reply message
+that would accompany a successful call; its tag is that
+of the failing request.
+.PP
+By convention, clients may truncate error messages after
+.B ERRMAX-1
+bytes;
+.B ERRMAX
+is defined in
+.BR <libc.h> .
diff --git a/sys/man/5/flush b/sys/man/5/flush
new file mode 100755
index 000000000..2ab7809e8
--- /dev/null
+++ b/sys/man/5/flush
@@ -0,0 +1,99 @@
+.TH FLUSH 5
+.SH NAME
+flush \- abort a message
+.SH SYNOPSIS
+.ta \w'\fLTflush 'u
+.IR size [4]
+.B Tflush
+.IR tag [2]
+.IR oldtag [2]
+.br
+.IR size [4]
+.B Rflush
+.IR tag [2]
+.SH DESCRIPTION
+When the response to a request is no longer needed, such as when
+a user interrupts a process doing a
+.IR read (2),
+a
+.B Tflush
+request is sent to the server to purge the pending response.
+The message being flushed is identified by
+.IR oldtag .
+The semantics of
+.B flush
+depends on messages arriving in order.
+.PP
+The server should answer the
+.B flush
+message immediately.
+If it recognizes
+.I oldtag
+as the tag of a pending transaction, it should abort any pending response
+and discard that tag.
+In either case, it should respond with an
+.B Rflush
+echoing the
+.I tag
+(not
+.IR oldtag )
+of the
+.B Tflush
+message.
+A
+.B Tflush
+can never be responded to by an
+.B Rerror
+message.
+.PP
+The server may respond to the pending request before
+responding to the
+.BR Tflush .
+It is possible for a client to send multiple
+.B Tflush
+messages for a particular pending request.  Each
+subsequent
+.B Tflush
+must contain as
+.I oldtag
+the tag of the pending request (not a previous
+.BR Tflush ).
+Should multiple
+.BR Tflush es
+be received for a pending request, they must be answered in
+order.  A
+.B Rflush
+for any of the multiple
+.BR Tflush es
+implies an answer for all previous ones.  Therefore, should
+a server receive a request and then multiple flushes for that
+request, it need respond only to the last flush.
+.PP
+When the client sends a 
+.BR Tflush ,
+it must wait to receive the corresponding
+.B Rflush
+before reusing
+.I oldtag
+for subsequent messages.
+If a response to the flushed request is received before the
+.BR Rflush ,
+the client must honor the response
+as if it had not been flushed,
+since the completed request may signify a state change in the server.
+For instance,
+.B Tcreate
+may have created a file and
+.B Twalk
+may have allocated a fid.
+If no response is received before the
+.BR Rflush ,
+the flushed transaction is considered to have been canceled,
+and should be treated as though it had never been sent.
+.PP
+Several exceptional conditions are handled correctly by the above specification:
+sending multiple flushes for a single tag,
+flushing after a transaction is completed,
+flushing a
+.BR Tflush ,
+and flushing an invalid tag.
diff --git a/sys/man/5/open b/sys/man/5/open
new file mode 100755
index 000000000..6672c694f
--- /dev/null
+++ b/sys/man/5/open
@@ -0,0 +1,247 @@
+.TH OPEN 5 
+.SH NAME
+open, create \- prepare a fid for I/O on an existing or new file
+.SH SYNOPSIS
+.ta \w'\fLTcreate 'u
+.IR size [4]
+.B Topen
+.IR tag [2]
+.IR fid [4]
+.IR mode [1]
+.br
+.IR size [4]
+.B Ropen
+.IR tag [2]
+.IR qid [13]
+.IR iounit [4]
+.PP
+.IR size [4]
+.B Tcreate
+.IR tag [2]
+.IR fid [4]
+.IR name [ s ]
+.IR perm [4]
+.IR mode [1]
+.br
+.IR size [4]
+.B Rcreate
+.IR tag [2]
+.IR qid [13]
+.IR iounit [4]
+.SH DESCRIPTION
+The
+.B open
+request asks the file server to check permissions and
+prepare a fid for I/O with subsequent
+.B read
+and
+.B write
+messages.
+The
+.I mode
+field determines the type of I/O:
+0
+(called
+.BR OREAD
+in
+.BR <libc.h> ),
+1
+.RB ( OWRITE ),
+2
+.RB ( ORDWR ),
+and 3
+.RB ( OEXEC )
+mean
+.I
+read access, write access, read and write access,
+and
+.I
+execute access,
+to be checked against the permissions for the file.
+In addition, if
+.I mode
+has the
+.B OTRUNC
+.RB ( 0x10 )
+bit set,
+the file is to be truncated, which requires write permission
+(if
+the file is append-only, and permission is granted, the
+.B open
+succeeds but the file will not be truncated);
+if the
+.I mode
+has the
+.B ORCLOSE
+.RB ( 0x40 )
+bit set, the file is to be removed when the fid
+is clunked, which requires permission to remove the file from its directory.
+All other bits in
+.I mode
+should be zero.
+It is illegal to write a directory, truncate it, or attempt to remove it on close.
+If the file is marked for exclusive use (see
+.IR stat (5)),
+only one client can have the file open at any time.
+That is, after such a file has been opened,
+further opens will fail until
+.I fid
+has been clunked.
+All these permissions are checked at the time of the
+.B open
+request; subsequent changes to the permissions of files do not affect
+the ability to read, write, or remove an open file.
+.PP
+The 
+.B create
+request asks the file server to create a new file
+with the 
+.I name
+supplied, in the directory
+.RI ( dir )
+represented by
+.IR fid ,
+and requires write permission in the directory.
+The owner of the file is the implied user id of the request,
+the group of the file is the same as
+.IR dir ,
+and the permissions are the value of
+.ce
+.B "perm & (~0666 | (dir.perm & 0666))"
+if a regular file is being created and
+.ce
+.B "perm & (~0777 | (dir.perm & 0777))"
+if a directory is being created.
+This means, for example, that if the
+.B create
+allows read permission to others, but the containing directory
+does not, then the created file will not allow others to read the file.
+.PP
+Finally, the newly created file is opened according to
+.IR mode ,
+and
+.I fid
+will represent the newly opened file.
+.I Mode
+is not checked against the permissions in
+.IR perm .
+The
+.I qid
+for the new file is returned with the
+.B create
+reply message.
+.PP
+Directories are created by setting the
+.B DMDIR
+bit
+.RB ( 0x80000000 )
+in the
+.IR perm .
+.PP
+The names
+.B .
+and
+.B ..
+are special; it is illegal to create files with these names.
+.PP
+It is an error for either of these messages if the fid
+is already the product of a successful
+.B open
+or
+.B create
+message.
+.PP
+An attempt to
+.B create
+a file in a directory where the given
+.I name
+already exists will be rejected;
+in this case, the
+.I create
+system call
+(see
+.IR open (2))
+uses
+.B open
+with truncation.
+The algorithm used by the
+.IR create
+system call
+is:
+first walk to the directory to contain the file.
+If that fails, return an error.
+Next
+.B walk
+to the specified file.
+If the
+.B walk
+succeeds, send a request to
+.B open
+and truncate the file and return the result, successful or not.
+If the
+.B walk
+fails, send a create message.
+If that fails, it may be because the file was created by another
+process after the previous walk failed, so (once) try the
+.B walk
+and
+.B open
+again.
+.PP
+For the behavior of
+.I create
+on a union directory, see
+.IR bind (2).
+.PP
+The
+.B iounit
+field returned by
+.B open
+and
+.B create
+may be zero.
+If it is not, it is the maximum number of bytes that are guaranteed to
+be read from or written to the file without breaking the I/O transfer
+into multiple 9P messages; see
+.IR read (5).
+.SH ENTRY POINTS
+.I Open
+and
+.I create
+both generate
+.B open
+messages; only
+.I create
+generates a
+.B create
+message.
+The
+.B iounit
+associated with an open file may be discovered by calling
+.IR iounit (2).
+.PP
+For programs that need atomic file creation, without the race
+that exists in the
+.B open-create
+sequence described above,
+the kernel does the following.
+If the
+.B OEXCL
+.RB ( 0x1000 )
+bit is set in the
+.I mode
+for a
+.B create
+system call,
+the
+.B open
+message is not sent; the kernel issues only the
+.BR create .
+Thus, if the file exists,
+.B create
+will draw an error, but if it doesn't and the
+.B create
+system call succeeds, the process issuing the
+.B create
+is guaranteed to be the one that created the file.
+
diff --git a/sys/man/5/read b/sys/man/5/read
new file mode 100755
index 000000000..4438ee984
--- /dev/null
+++ b/sys/man/5/read
@@ -0,0 +1,125 @@
+.TH READ 5 
+.SH NAME
+read, write \- transfer data from and to a file
+.SH SYNOPSIS
+.ta \w'\fLTwrite 'u
+.IR size [4]
+.B Tread
+.IR tag [2]
+.IR fid [4]
+.IR offset [8]
+.IR count [4]
+.br
+.IR size [4]
+.B Rread
+.IR tag [2]
+.IR count [4]
+.IR data [ count ]
+.PP
+.IR size [4]
+.B Twrite
+.IR tag [2]
+.IR fid [4]
+.IR offset [8]
+.IR count [4]
+.IR data [ count ]
+.br
+.IR size [4]
+.B Rwrite
+.IR tag [2]
+.IR count [4]
+.SH DESCRIPTION
+The
+.B read
+request
+asks for
+.I count
+bytes of data
+from the file identified by 
+.IR fid ,
+which must be opened for reading,
+starting 
+.I offset
+bytes after the beginning of the file.
+The bytes are returned with the
+.B read
+reply message.
+.PP
+The
+.I count
+field in the reply indicates the number of bytes returned.
+This may be less than the requested amount.
+If the
+.I offset
+field is greater than or equal to the number of bytes in the file,
+a count of zero will be returned.
+.PP
+For directories,
+.B read
+returns an integral number of
+directory entries exactly as in
+.B stat
+(see
+.IR stat (5)),
+one for each member of the directory.
+The
+.B read
+request message must have
+.B offset
+equal to zero or the value of
+.B offset
+in the previous
+.B read
+on the directory, plus the number of bytes
+returned in the previous
+.BR read .
+In other words, seeking other than to the beginning
+is illegal in a directory (see
+.IR seek (2)).
+.PP
+The
+.B write
+request asks that
+.I count
+bytes of data be recorded in the file identified by
+.IR fid ,
+which must be opened for writing, starting
+.I offset
+bytes after the beginning of the file.
+If the file is append-only,
+the data will be placed at the end of the file regardless of
+.IR offset .
+Directories may not be written.
+.PP
+The 
+.B write
+reply records the number of bytes actually written.
+It is usually an error
+if this is not the same as requested.
+.PP
+Because 9P implementations may limit the size of individual
+messages,
+more than one message may be produced by a single
+.I read
+or
+.I write
+call.
+The
+.I iounit
+field returned by
+.IR open (5),
+if non-zero, reports the maximum size that is guaranteed
+to be transferred atomically.
+.SH ENTRY POINTS
+.B Read
+and
+.B write
+messages are generated by the corresponding calls.
+Because they include an offset, the
+.I pread
+and
+.I pwrite
+calls correspond more directly to the 9P messages.
+Although
+.IR seek (2)
+affects the offset, it does not generate a message.
diff --git a/sys/man/5/remove b/sys/man/5/remove
new file mode 100755
index 000000000..ccdc1b3dd
--- /dev/null
+++ b/sys/man/5/remove
@@ -0,0 +1,49 @@
+.TH REMOVE 5 
+.SH NAME
+remove \- remove a file from a server
+.SH SYNOPSIS
+.ta \w'\fLTremove 'u
+.IR size [4]
+.B Tremove
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rremove
+.IR tag [2]
+.SH DESCRIPTION
+The
+.B remove
+request asks the file server both to remove the file represented by
+.I fid
+and to
+.B clunk
+the
+.IR fid ,
+even if the remove fails.
+This request will fail if the client does not have write permission
+in the parent directory.
+.PP
+It is correct to consider
+.B remove
+to be a
+.B clunk
+with the side effect of removing the file if permissions allow.
+.PP
+If a file has been opened as multiple fids,
+possibly on different connections,
+and one fid is used to remove the file,
+whether the other fids continue to provide access to the file
+is implementation-defined.
+The Plan 9 file servers (like
+.IR fs (4))
+remove the file immediately: attempts to use the other fids
+will yield a
+``phase error.''
+.IR U9fs (4)
+follows the semantics of the underlying Unix file system,
+so other fids typically remain usable.
+.SH ENTRY POINTS
+.B Remove
+messages are generated by
+.IR remove .
diff --git a/sys/man/5/stat b/sys/man/5/stat
new file mode 100755
index 000000000..29c02011f
--- /dev/null
+++ b/sys/man/5/stat
@@ -0,0 +1,298 @@
+.TH STAT 5 
+.SH NAME
+stat, wstat \- inquire or change file attributes
+.SH SYNOPSIS
+.ta \w'\fLTwstat 'u
+.IR size [4]
+.B Tstat
+.IR tag [2]
+.IR fid [4]
+.br
+.IR size [4]
+.B Rstat
+.IR tag [2]
+.IR stat [ n ]
+.PP
+.IR size [4]
+.B Twstat
+.IR tag [2]
+.IR fid [4]
+.IR stat [ n ]
+.br
+.IR size [4]
+.B Rwstat
+.IR tag [2]
+.SH DESCRIPTION
+The
+.B stat
+transaction inquires about the file
+identified by
+.IR fid .
+The reply will contain a
+machine-independent
+.I directory
+.IR entry ,
+.IR stat ,
+laid out as follows:
+.TP
+.I size\f1[2]\fP
+total byte count of the following data
+.TP
+.I type\f1[2]\fP
+for kernel use
+.TP
+.I dev\f1[4]\fP
+for kernel use
+.TP
+.I qid.type\f1[1]\fP
+the type of the file (directory, etc.), represented as a bit vector
+corresponding to the high 8 bits of the file's mode word.
+.TP
+.I qid.vers\f1[4]\fP
+version number for given path
+.TP
+.I qid.path\f1[8]\fP
+the file server's unique identification for the file
+.TP
+.I mode\f1[4]\fP
+permissions and flags
+.TP
+.I atime\f1[4]\fP
+last access time
+.TP
+.I mtime\f1[4]\fP
+last modification time
+.TP
+.I length\f1[8]\fP
+length of file in bytes
+.TP
+.I name\f1[ s ]\fP
+file name; must be
+.B /
+if the file is the root directory of the server
+.TP
+.I uid\f1[ s ]\fP
+owner name
+.TP
+.I gid\f1[ s ]\fP
+group name
+.TP
+.I muid\f1[ s ]\fP
+name of the user who last modified the file
+.PD
+.PP
+Integers in this encoding are in little-endian order (least
+significant byte first).
+The
+.I convM2D
+and
+.I convD2M
+routines (see
+.IR fcall (2))
+convert between directory entries and a C structure called a
+.BR Dir .
+.PP
+The
+.I mode
+contains permission bits as described in
+.IR intro (5)
+and the following:
+.B 0x80000000
+.RB ( DMDIR ,
+this file is a directory),
+.B 0x40000000
+.RB ( DMAPPEND ,
+append only),
+.B 0x20000000
+.RB ( DMEXCL ,
+exclusive use),
+.B 0x04000000
+.RB ( DMTMP ,
+temporary);
+these are echoed in
+.BR Qid.type .
+Writes to append-only files always place their data at the
+end of the file; the
+.I offset
+in the
+.B write
+message is ignored, as is the
+.B OTRUNC
+bit in an open.
+Exclusive use files may be open for I/O by only one fid at a time
+across all clients of the server.  If a second open is attempted,
+it draws an error.  Servers may implement a timeout on the lock
+on an exclusive use file: if the fid holding the file open has
+been unused for an extended period (of order at least minutes),
+it is reasonable to break the lock and deny the initial fid
+further I/O.
+Temporary files are not included in nightly archives
+(see
+.IR fossil (4)).
+.PP
+The two time fields are measured in seconds since the epoch
+(Jan 1 00:00 1970 GMT).
+The
+.I mtime
+field reflects the time of the last change of content (except when later changed by
+.BR wstat ).
+For a plain file,
+.I mtime
+is the time of the most recent
+.BR create ,
+.B open
+with truncation,
+or
+.BR write ;
+for a directory it is the time of the most recent
+.BR remove ,
+.BR create ,
+or
+.B wstat
+of a file in the directory.
+Similarly, the
+.I atime
+field records the last
+.B read
+of the contents;
+also it is set whenever
+.I mtime
+is set.
+In addition, for a directory, it is set by
+an
+.BR attach ,
+.BR walk ,
+or
+.BR create ,
+all whether successful or not.
+.PP
+The
+.I muid
+field names the user whose actions most recently changed the
+.I mtime
+of the file.
+.PP
+The
+.I length
+records the number of bytes in the file.
+Directories and most files representing devices have a conventional
+length of 0.
+.PP
+The
+.B stat
+request requires no special permissions.
+.PP
+The
+.B wstat
+request can change some of the file status information.
+The
+.I name
+can be changed by anyone with write permission in the parent directory;
+it is an error to change the name to that of an existing file.
+The
+.I length
+can be changed (affecting the actual length of the file) by anyone with
+write permission on the file.
+It is an error to attempt to set the length of a directory to a non-zero value,
+and servers may decide to reject length changes for other reasons.
+The
+.I mode
+and
+.I mtime
+can be changed by the owner of the file or the group leader of the file's current
+group.
+The directory bit cannot be changed by a
+.BR wstat ;
+the other defined permission and mode bits can.
+The
+.I gid
+can be changed: by the owner if also a member of the new group; or
+by the group leader of the file's current group
+if also leader of the new group
+(see
+.IR intro (5)
+for more information about permissions and
+.IR users (6)
+for users and groups).
+None of the other data can be altered by a
+.B wstat
+and attempts to change them will trigger an error.
+In particular,
+it is illegal to attempt to change the owner of a file.
+(These conditions may be
+relaxed when establishing the initial state of a file server; see
+.IR fsconfig (8).)
+.PP
+Either all the changes in
+.B wstat
+request happen, or none of them does: if the request succeeds,
+all changes were made; if it fails, none were.
+.PP
+A
+.B wstat
+request can avoid modifying some properties of the file
+by providing explicit ``don't touch'' values in the
+.B stat
+data that is sent: zero-length strings for text values and
+the maximum unsigned value of appropriate size
+for integral values.
+As a special case, if
+.I all
+the elements of the directory entry in a
+.B Twstat
+message are ``don't touch'' values, the server may interpret it
+as a request to guarantee that the contents of the associated
+file are committed to stable storage before the
+.B Rwstat
+message is returned.
+(Consider the message to mean, ``make the state of the file
+exactly what it claims to be.'')
+.PP
+A
+.I read
+of a directory yields an integral number of directory entries in
+the machine independent encoding given above
+(see
+.IR read (5)).
+.PP
+Note that since the
+.B stat
+information is sent as a 9P variable-length datum, it is limited to a maximum of
+65535 bytes.
+.SH ENTRY POINTS
+.B Stat
+messages are generated by
+.I fstat
+and
+.IR stat .
+.PP
+.B Wstat
+messages are generated by
+.I fwstat
+and
+.IR wstat .
+.SH BUGS
+To make the contents of a directory, such as returned by
+.IR read (5),
+easy to parse, each
+directory entry begins with a size field.
+For consistency, the entries in
+.B Twstat
+and
+.B Rstat
+messages also contain
+their size, which means the size appears twice.
+For example, the
+.B Rstat
+message is formatted as
+.RI ``(4+1+2+2+ n )[4]
+.B Rstat
+.IR tag [2]
+.IR n [2]
+.RI ( n -2)[2]
+.IR type [2]
+.IR dev [4]...,''
+where 
+.I n
+is the value returned by
+.BR convD2M .
diff --git a/sys/man/5/version b/sys/man/5/version
new file mode 100755
index 000000000..c7236e2e7
--- /dev/null
+++ b/sys/man/5/version
@@ -0,0 +1,101 @@
+.TH VERSION 5 
+.SH NAME
+version \- negotiate protocol version
+.SH SYNOPSIS
+.ta \w'\fLTversion 'u
+.IR size [4]
+.B Tversion
+.IR tag [2]
+.IR msize [4]
+.IR version [ s ]
+.br
+.IR size [4]
+.B Rversion
+.IR tag [2]
+.IR msize [4]
+.IR version [ s ]
+.SH DESCRIPTION
+The 
+.B version
+request negotiates the protocol version and message size
+to be used on the connection and initializes the connection for I/O.
+.B Tversion
+must be the first message sent on the 9P connection,
+and the client cannot issue any further requests until it has received the
+.B Rversion
+reply.
+The
+.I tag
+should be
+.B NOTAG
+(value
+.BR (ushort)~0 )
+for a
+.B version
+message.
+.PP
+The client suggests a maximum message size,
+.BR msize ,
+that is the maximum length, in bytes,
+it will ever generate or expect to receive in a single 9P message.
+This count includes all 9P protocol data, starting from the
+.B size
+field and extending through the message,
+but excludes enveloping transport protocols.
+The server responds with its own maximum,
+.BR msize ,
+which must be less than or equal to the client's value.
+Thenceforth, both sides of the connection must honor this limit.
+.PP
+The
+.B version
+string identifies the level of the protocol.
+The string must always begin with the two characters
+.RB `` 9P ''.
+If the server does not understand the client's version string,
+it should respond with an
+.B Rversion
+message (not
+.BR Rerror )
+with the
+.B version
+string the 7 characters
+.RB `` unknown ''.
+.PP
+The server may respond with the client's version string,
+or a version string identifying
+an earlier defined protocol version.
+Currently, the only defined version is the 6 characters
+.RB `` 9P2000 ''.
+Version strings are defined such that, if the client string contains
+one or more period characters, the initial substring up to but not including
+any single period in the version string defines a version of the protocol.
+After stripping any such period-separated suffix, the server is allowed to respond
+with a string of the form
+.BI 9P nnnn\f1,
+where
+.I nnnn
+is less than or equal to the digits sent by the client.
+.PP
+The client and server will use the protocol version defined by the
+server's response for all subsequent communication on the connection.
+.PP
+A successful
+.B version
+request initializes the connection.
+All outstanding I/O on the connection is aborted; all active fids are freed (`clunked') automatically.
+The set of messages between
+.B version
+requests is called a
+.IR session .
+.SH ENTRY POINTS
+The
+.B version
+message is generated by the
+.B fversion
+system call.
+It is also generated automatically, if required, by a
+.B mount
+or
+.B fauth
+system call on an uninitialized connection.
diff --git a/sys/man/5/walk b/sys/man/5/walk
new file mode 100755
index 000000000..61439459b
--- /dev/null
+++ b/sys/man/5/walk
@@ -0,0 +1,178 @@
+.TH WALK 5 
+.SH NAME
+walk \- descend a directory hierarchy
+.SH SYNOPSIS
+.ta \w'\fLTwalk 'u
+.IR size [4]
+.B Twalk
+.IR tag [2]
+.IR fid [4]
+.IR newfid [4]
+.IR nwname [2]
+.IR nwname *( wname [ s ])
+.br
+.IR size [4]
+.B Rwalk
+.IR tag [2]
+.IR nwqid [2]
+.IR nwqid *( qid [13])
+.SH DESCRIPTION
+The 
+.B walk
+request carries as arguments an existing 
+.IR fid
+and a proposed
+.I newfid
+(which must not be in use unless it is the same as
+.IR fid )
+that the client wishes to associate with
+the result of traversing the directory hierarchy
+by `walking' the hierarchy using the successive path name
+elements
+.BR wname .
+The
+.I fid
+must represent a directory unless zero path name elements are specified.
+.PP
+The
+.I fid
+must be valid in the current session and must not have been opened for I/O
+by an
+.B open
+or
+.B create
+message.
+If the full sequence of
+.B nwname
+elements is walked successfully,
+.I newfid
+will represent the file that results.
+If not,
+.I newfid
+(and
+.BR fid )
+will be unaffected.
+However, if
+.I newfid
+is in use or otherwise illegal, an
+.B Rerror
+is returned.
+.PP
+The name
+.RB `` .. ''
+(dot-dot) represents the parent directory.
+The name
+.RB `` . ''
+(dot), meaning the current directory, is not used in the protocol.
+.PP
+It is legal for
+.B nwname
+to be zero, in which case
+.I newfid
+will represent the same file as
+.I fid
+and the
+.B walk
+will usually succeed; this is equivalent to walking to dot.
+The rest of this discussion assumes
+.B nwname
+is greater than zero.
+.PP
+The
+.B nwname
+path name elements
+.B wname
+are walked in order, ``elementwise''.
+For the first elementwise walk
+to succeed, the file identified by
+.I fid
+must be a directory,
+and the implied user of the request must have permission
+to search the directory (see
+.IR intro (5)).
+Subsequent elementwise walks have equivalent restrictions
+applied to the implicit fid that results from the preceding elementwise walk.
+.PP
+If the first element cannot be walked for any reason,
+.B Rerror
+is returned.
+Otherwise, the walk will return an
+.B Rwalk
+message containing
+.I nwqid
+qids corresponding, in order, to the files that are visited by the
+.I nwqid
+successful elementwise walks;
+.I nwqid
+is therefore either
+.B nwname
+or the index of the first elementwise walk that failed.
+The value of
+.I nwqid
+cannot be zero unless
+.B nwname
+is zero.
+Also,
+.I nwqid
+will always be less than or equal to
+.BR nwname .
+Only if it is equal, however, will
+.I newfid
+be affected, in which case
+.I newfid
+will represent the file
+reached by the final elementwise walk requested in the message.
+.PP
+A
+.B walk
+of the name
+.RB `` .. ''
+in the root directory of a server is equivalent to a walk with no name elements.
+.PP
+If
+.I newfid
+is the same as
+.IR fid ,
+the above discussion applies, with the obvious difference
+that if the walk changes the state of
+.IR newfid ,
+it also changes the state of
+.IR fid ;
+and if
+.I newfid
+is unaffected, then
+.I fid
+is also unaffected.
+.PP
+To simplify the implementation of the servers, a maximum of sixteen name elements or qids
+may be packed in a single message.
+This constant is called
+.B MAXWELEM
+in
+.IR fcall (2).
+Despite this restriction, the system imposes no limit on the number of elements in a file name,
+only the number that may be transmitted in a single message.
+.SH ENTRY POINTS
+A call to
+.IR chdir (2)
+causes a
+.BR walk .
+One or more
+.B walk
+messages may be generated by
+any of the following calls, which evaluate file names:
+.IR bind ,
+.IR create ,
+.IR exec ,
+.IR mount ,
+.IR open ,
+.IR remove ,
+.IR stat ,
+.IR unmount ,
+.IR wstat .
+The file name element
+.B .
+(dot) is interpreted locally and
+is not transmitted in
+.B walk
+messages.