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

author: Taru Karttunen <taruti@taruti.net> 2011-03-30 16:49:47 +0300
committer: Taru Karttunen <taruti@taruti.net> 2011-03-30 16:49:47 +0300
commit: b41b9034225ab3e49980d9de55c141011b6383b0 (patch)
tree: 891014b4c2e803e01ac7a1fd2b60819fbc5a6e73 /sys/man/4
parent: c558a99e0be506a9abdf677f0ca4490644e05fc1 (diff)
48 files changed, 9991 insertions, 0 deletions
diff --git a/sys/man/4/0intro b/sys/man/4/0intro
new file mode 100755
index 000000000..8a3a6a3dd
--- /dev/null
+++ b/sys/man/4/0intro
@@ -0,0 +1,14 @@
+.TH INTRO 4
+.SH NAME
+intro \- introduction to file servers
+.SH DESCRIPTION
+A Plan 9
+.I "file server"
+provides a file tree to processes.
+This section of the manual describes servers than can be
+mounted in a name space to give a file-like interface to interesting services.
+A file server may be a provider of a conventional file system,
+with files maintained on permanent storage,
+or it may also be a process that synthesizes files in some manner.
+.SH SEE ALSO
+.IR bind (1)
diff --git a/sys/man/4/INDEX b/sys/man/4/INDEX
new file mode 100755
index 000000000..cc3639010
--- /dev/null
+++ b/sys/man/4/INDEX
@@ -0,0 +1,91 @@
+0intro 0intro
+intro 0intro
+acme acme
+archfs archfs
+cddb cdfs
+cdfs cdfs
+cfs cfs
+cifs cifs
+C consolefs
+clog consolefs
+consolefs consolefs
+cwfs cwfs
+9660srv dossrv
+9fat: dossrv
+a: dossrv
+b: dossrv
+c: dossrv
+d: dossrv
+dosmnt dossrv
+dossrv dossrv
+eject dossrv
+execnet execnet
+exportfs exportfs
+srvfs exportfs
+ext2srv ext2srv
+factotum factotum
+fgui factotum
+flashfs flashfs
+flchk fossil
+flfmt fossil
+fossil fossil
+fs fs
+ftpfs ftpfs
+httpfile httpfile
+import import
+iostats iostats
+keyfs keyfs
+warning keyfs
+kfs kfs
+lnfs lnfs
+mntgen mntgen
+namespace namespace
+nfs nfs
+nntpfs nntpfs
+paqfs paqfs
+plumber plumber
+ramfs ramfs
+ratfs ratfs
+rdbfs rdbfs
+rio rio
+sacfs sacfs
+snap snap
+snapfs snap
+9fs srv
+srv srv
+srvold9p srv
+srvssh srv
+32vfs tapefs
+cpiofs tapefs
+tapefs tapefs
+tapfs tapefs
+tarfs tapefs
+tpfs tapefs
+v10fs tapefs
+v6fs tapefs
+zipfs tapefs
+fax telco
+faxreceive telco
+faxsend telco
+telco telco
+telcodata telco
+telcofax telco
+u9fs u9fs
+upasfs upasfs
+audio usb
+ccid usb
+disk usb
+ether usb
+kb usb
+print usb
+probe usb
+serial usb
+usb usb
+usbeject usb
+usbfat: usb
+usbd usbd
+vacfs vacfs
+webcookies webcookies
+webfs webfs
+wikifs wikifs
+wikipost wikifs
diff --git a/sys/man/4/INDEX.html b/sys/man/4/INDEX.html
new file mode 100755
index 000000000..36466a687
--- /dev/null
+++ b/sys/man/4/INDEX.html
@@ -0,0 +1,193 @@
+<HEAD>
+<TITLE>plan 9 man section 4</TITLE>
+</HEAD>
+<BODY>
+<B>[<A HREF="/sys/man/index.html">manual index</A>]</B>
+<H2>Plan 9 from Bell Labs - Section 4 - File Servers</H2>
+<HR>
+<DL>
+<DT><A HREF="/magic/man2html/4/0intro">0intro</A>
+-  introduction to file servers
+<DD><TT> intro</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/acme">acme</A>
+-  control files for text windows
+<DD><TT> acme</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/archfs">archfs</A>
+-  mount mkfs-style archive
+<DD><TT> archfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/cdfs">cdfs</A>
+-  optical disc (CD, DVD, BD) track reader and writer file system
+<DD><TT> cdfs, cddb</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/cfs">cfs</A>
+-  cache file system
+<DD><TT> cfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/cifs">cifs</A>
+-  Microsoft™ Windows network filesystem client
+<DD><TT> cifs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/consolefs">consolefs</A>
+-  file system for console access
+<DD><TT> consolefs, C, clog</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/cwfs">cwfs</A>
+-  cached-worm file server, dump
+<DD><TT> cwfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/dossrv">dossrv</A>
+-  DOS and ISO9660 file systems
+<DD><TT> dossrv, 9660srv, a:, b:, c:, d:, 9fat:, dosmnt, eject</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/execnet">execnet</A>
+-  network interface to program execution
+<DD><TT> execnet</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/exportfs">exportfs</A>
+-  network file server plumbing
+<DD><TT> exportfs, srvfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/ext2srv">ext2srv</A>
+-  ext2 file system
+<DD><TT> ext2srv</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/factotum">factotum</A>
+-  authentication agent
+<DD><TT> factotum, fgui</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/flashfs">flashfs</A>
+-  journalling file system for flash memory
+<DD><TT> flashfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/fossil">fossil</A>
+-  archival file server
+<DD><TT> fossil, flchk, flfmt</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/fs">fs</A>
+-  file server, dump
+<DD><TT> fs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/ftpfs">ftpfs</A>
+-  file transfer protocol (FTP) file system
+<DD><TT> ftpfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/httpfile">httpfile</A>
+-  serve a single web file
+<DD><TT> httpfile</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/import">import</A>
+-  import a name space from a remote system
+<DD><TT> import</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/iostats">iostats</A>
+-  file system to measure I/O
+<DD><TT> iostats</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/keyfs">keyfs</A>
+-  authentication database files
+<DD><TT> keyfs, warning</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/kfs">kfs</A>
+-  disk file system
+<DD><TT> kfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/lnfs">lnfs</A>
+-  long name file system
+<DD><TT> lnfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/mntgen">mntgen</A>
+-  automatically generate mount points for file systems
+<DD><TT> mntgen</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/namespace">namespace</A>
+-  structure of conventional file name space
+<DD><TT> namespace</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/nfs">nfs</A>
+-  Sun network file system client
+<DD><TT> nfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/nntpfs">nntpfs</A>
+-  network news transport protocol (NNTP) file system
+<DD><TT> nntpfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/paqfs">paqfs</A>
+-  compressed read-only file system
+<DD><TT> paqfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/plumber">plumber</A>
+-  file system for interprocess messaging
+<DD><TT> plumber</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/ramfs">ramfs</A>
+-  memory file system
+<DD><TT> ramfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/ratfs">ratfs</A>
+-  mail address ratification file system
+<DD><TT> ratfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/rdbfs">rdbfs</A>
+-  remote kernel debugging file system
+<DD><TT> rdbfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/rio">rio</A>
+-  window system files
+<DD><TT> rio</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/sacfs">sacfs</A>
+-  compressed file system
+<DD><TT> sacfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/snap">snap</A>
+-  create and mount process snapshots
+<DD><TT> snap, snapfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/srv">srv</A>
+-  start network file service
+<DD><TT> srv, srvold9p, 9fs, srvssh</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/tapefs">tapefs</A>
+-  mount archival file systems
+<DD><TT> 32vfs, cpiofs, tapfs, tarfs, tpfs, v6fs, v10fs, zipfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/telco">telco</A>
+-  telephone dialer network
+<DD><TT> telco, faxreceive, faxsend, fax, telcofax, telcodata</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/u9fs">u9fs</A>
+-  serve 9P from Unix
+<DD><TT> u9fs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/upasfs">upasfs</A>
+-  mail file server
+<DD><TT> upasfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/usb">usb</A>
+-  Universal Serial Bus device drivers
+<DD><TT> audio, ccid, disk, ether, kb, print, probe, serial, usbeject, usbfat:</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/usbd">usbd</A>
+-  Universal Serial Bus daemon
+<DD><TT> usbd</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/vacfs">vacfs</A>
+-  a Venti-based file system
+<DD><TT> vacfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/webcookies">webcookies</A>
+-  HTTP cookie manager
+<DD><TT> webcookies</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/webfs">webfs</A>
+-  world wide web file system
+<DD><TT> webfs</TT>
+</DT>
+<DT><A HREF="/magic/man2html/4/wikifs">wikifs</A>
+-  wiki file system
+<DD><TT> wikifs, wikipost</TT>
+</DT>
+</DL>
diff --git a/sys/man/4/acme b/sys/man/4/acme
new file mode 100755
index 000000000..a2e68ddf1
--- /dev/null
+++ b/sys/man/4/acme
@@ -0,0 +1,458 @@
+.TH ACME 4
+.SH NAME
+acme \- control files for text windows
+.SH SYNOPSIS
+.B acme
+[
+.B -ab
+]
+[
+.B -c
+.I ncol
+]
+[
+.B -f
+.I varfont
+]
+[
+.B -F
+.I fixfont
+]
+[
+.B -l
+.I file
+|
+.I file
+\&... ]
+.SH DESCRIPTION
+The text window system
+.IR acme (1)
+serves a variety of files for reading, writing, and controlling
+windows.
+Some of them are virtual versions of system files for dealing
+with the virtual console; others control operations
+of 
+.I acme
+itself.
+When a command is run under
+.IR acme ,
+a directory holding these files is mounted on
+.B /mnt/acme
+(also bound to
+.BR /mnt/wsys )
+and also
+.BR /dev ;
+the files mentioned here
+appear in both those directories.
+.PP
+Some of these files supply virtual versions of services available from the underlying
+environment, in particular the character terminal files
+.IR cons (3).
+(Unlike in
+.IR rio (1),
+each command under
+.I acme
+sees the same set of files; there is not a distinct
+.B /dev/cons
+for each window.)
+Other files are unique to
+.IR acme .
+.TP
+.B acme
+is a subdirectory used by
+.B win
+(see
+.IR acme (1))
+as a mount point for the
+.I acme
+files associated with the window in which
+.B win
+is running.
+It has no specific function under
+.I acme
+itself.
+.TP
+.B cons
+is the standard and diagnostic output file for all commands
+run under
+.IR acme .
+(Input for commands is redirected to
+.BR /dev/null .)
+Text written to
+.B cons
+appears in a window labeled
+.IB dir /+Errors\f1,
+where
+.I dir
+is the directory in which the command
+was run.
+The window is created if necessary, but not until text is actually written.
+.TP
+.B consctl
+Is an empty unwritable file present only for compatibility; there is no way
+to turn off `echo', for example, under
+.IR acme .
+.TP
+.B index
+holds a sequence of lines of text, one per window.  Each line has 5 decimal numbers,
+each formatted in 11 characters plus a blank\(emthe window ID;
+number of characters (runes) in the tag;
+number of characters in the body;
+a 1 if the window is a directory, 0 otherwise;
+and a 1 if the window is modified, 0
+otherwise\(emfollowed by the tag up to a newline if present.
+Thus at character position 5×12 starts the name of the window.
+If a file has multiple zeroxed windows open,
+only the most recently used will appear in the
+.B index
+file.
+.TP
+.B label
+is an empty file, writable without effect, present only for compatibility with
+.BR rio .
+.TP
+.B new
+A directory analogous to the numbered directories
+.RI ( q.v. ).
+Accessing any
+file in
+.B new
+creates a new window.  Thus to cause text to appear in a new window,
+write it to
+.BR /dev/new/body .
+For more control, open
+.BR /dev/new/ctl
+and use the interface described below.
+.LP
+.PP
+Each
+.I acme
+window has associated a directory numbered by its ID.
+Window IDs are chosen sequentially and may be discovered by the
+.B ID
+command, by
+reading the
+.B ctl
+file, or
+indirectly through the
+.B index
+file.  The files in the numbered directories are as follows.
+.TP
+.B addr
+may be written with any textual address (line number, regular expression, etc.),
+in the format understood by button 3 but without the initial colon, including compound addresses,
+to set the address for text accessed through the
+.B data
+file.
+When read, it returns the value of the address that would next be read
+or written through the
+.B data
+file, formatted as 2 decimal numbers
+.I m
+and
+.IR n ,
+each formatted in 11 characters plus a blank.
+.I M
+and
+.I n
+are the character (not byte) offsets of the
+beginning and end of the address, 
+which would be expressed in
+.I acme 's
+input language as 
+.BI # m ,# n \fR.
+Thus a regular expression may be evaluated by writing it to
+.B addr
+and reading it back.
+The
+.B addr
+address has no effect on the user's selection of text.
+.TP
+.B body
+holds contents of the window body.  It may be read at any byte offset.
+Text written to
+.B body
+is always appended; the file offset is ignored.
+.TP
+.B ctl
+may be read to recover the five numbers as held in the
+.B index
+file, described above, plus three more fields: the width of the
+window in pixels, the name of the font used in the window,
+and the width of a tab character in pixels.
+Text messages may be written to
+.B ctl
+to affect the window.
+Each message is terminated by a newline and multiple
+messages may be sent in a single write.
+.RS .5i
+.TF limit=addr
+.TP
+.B addr=dot
+Set the
+.B addr
+address to that of the user's selected text in the window.
+.TP
+.B clean
+Mark the window clean as though it has just been written.
+.TP
+.B dirty
+Mark the window dirty, the opposite of clean.
+.TP
+.B cleartag
+Remove all text in the tag after the vertical bar.
+.TP
+.B del
+Equivalent to the
+.B Del
+interactive command.
+.TP
+.B delete
+Equivalent to the
+.B Delete
+interactive command.
+.TP
+.B dot=addr
+Set the user's selected text in the window to the text addressed by the
+.B addr
+address.
+.TP
+.BI dump " command
+Set the command string to recreate the window from a dump file.
+.TP
+.BI dumpdir " directory
+Set the directory in which to run the command to recreate the window from a dump file.
+.TP
+.B get
+Equivalent to the
+.B Get
+interactive command with no arguments; accepts no arguments.
+.TP
+.B limit=addr
+When the
+.B ctl
+file is first opened, regular expression context searches in
+.B addr
+addresses examine the whole file; this message restricts subsequent
+searches to the current
+.B addr
+address.
+.TP
+.B mark
+Cancel
+.BR nomark ,
+returning the window to the usual state wherein each modification to the
+body must be undone individually.
+.TP
+.B menu
+Maintain
+.BR Undo ,
+.BR Redo ,
+and
+.B Put
+in the left half of the tag.
+(This is the default for file windows.)
+.TP
+.BI name " name
+Set the name of the window to
+.IR name .
+.TP
+.B nomark
+Turn off automatic `marking' of changes, so a set of related changes
+may be undone in a single
+.B Undo
+interactive command.
+.TP
+.B nomenu
+Do not maintain
+.BR Undo ,
+.BR Redo ,
+and
+.B Put
+in the left half of the tag.
+(This is the default for directory and error windows.)
+.TP
+.B noscroll
+Turn off automatic `scrolling' of the window to show text written to the body.
+.TP
+.B put
+Equivalent to the
+.B Put
+interactive command with no arguments; accepts no arguments.
+.TP
+.B scroll
+Cancel a
+.B noscroll
+message, returning the window to the default state wherein each write
+to the
+.B body
+file causes the window to `scroll' to display the new text.
+.TP
+.B show
+Guarantee at least some of the selected text is visible on the display.
+.RE
+.PD
+.TP
+.B data
+is used in conjunction with
+.B addr
+for random access to the contents of the body.
+The file offset is ignored when writing the
+.B data
+file; instead the location of the data to be read or written is determined by the state of the
+.B addr
+file.
+Text, which must contain only whole characters (no `partial runes'),
+written to
+.B data
+replaces the characters addressed by the
+.B addr
+file and sets the address to the null string at the end of the written text.
+A read from
+.B data
+returns as many whole characters as the read count will permit starting
+at the beginning of the
+.B addr
+address (the end of the address has no effect)
+and sets the address to the null string at the end of the returned
+characters.
+.TP
+.B errors
+Writing to the
+.B errors
+file appends to the body of the
+.IB dir /+Errors
+window, where
+.I dir
+is the directory currently named in the tag.
+The window is created if necessary,
+but not until text is actually written.
+.TP
+.B event
+When a window's
+.B event
+file is open, changes to the window occur as always but the
+actions are also reported as
+messages to the reader of the file.  Also, user actions with buttons 2 and 3
+(other than chorded
+.B Cut
+and
+.BR Paste ,
+which behave normally) have no immediate effect on the window;
+it is expected that the program reading the
+.B event
+file will interpret them.
+The messages have a fixed format:
+a character indicating the origin or cause of the action,
+a character indicating the type of the action,
+four free-format blank-terminated decimal numbers,
+optional text, and a newline.
+The first and second numbers are the character addresses of the action,
+the third is a flag,
+and the final is a count of the characters in the optional text, which
+may itself contain newlines.
+The origin characters are
+.B E
+for writes to the
+.B body
+or
+.B tag
+file,
+.B F
+for actions through the window's other files,
+.B K
+for the keyboard, and
+.B M
+for the mouse.
+The type characters are
+.B D
+for text deleted from the body,
+.B d
+for text deleted from the tag,
+.B I
+for text inserted to the body,
+.B i
+for text inserted to the tag,
+.B L
+for a button 3 action in the body,
+.B l
+for a button 3 action in the tag,
+.B X
+for a button 2 action in the body, and
+.B x
+for a button 2 action in the tag.
+.IP
+If the relevant text has less than 256 characters, it is included in the message;
+otherwise it is elided, the fourth number is 0, and the program must read
+it from the
+.B data
+file if needed.  No text is sent on a
+.B D
+or
+.B d
+message.
+.IP
+For
+.BR D ,
+.BR d ,
+.BR I ,
+and
+.BR i
+the flag is always zero.
+For
+.BR X
+and
+.BR x ,
+the flag is a bitwise OR (reported decimally) of the following:
+1 if the text indicated is recognized as an
+.I acme
+built-in command;
+2 if the text indicated is a null string that has a non-null expansion;
+if so, another complete message will follow describing the expansion
+exactly as if it had been indicated explicitly (its flag will always be 0);
+8 if the command has an extra (chorded) argument; if so,
+two more complete messages will follow reporting the argument (with
+all numbers 0 except the character count) and where it originated, in the form of
+a fully-qualified button 3 style address.
+.IP
+For
+.B L
+and
+.BR l ,
+the flag is the bitwise OR of the following:
+1 if
+.I acme
+can interpret the action without loading a new file;
+2 if a second (post-expansion) message follows, analogous to that with
+.B X
+messages;
+4 if the text is a file or window name (perhaps with address) rather than
+plain literal text.
+.IP
+For messages with the 1 bit on in the flag,
+writing the message back to the
+.B event
+file, but with the flag, count, and text omitted,
+will cause the action to be applied to the file exactly as it would
+have been if the
+.B event
+file had not been open.
+.TP
+.B tag
+holds contents of the window tag.  It may be read at any byte offset.
+Text written to
+.B tag
+is always appended; the file offset is ignored.
+.TP
+.B xdata
+The
+.B xdata
+file like
+.B data
+except that reads stop at the end address.
+.SH SOURCE
+.B /sys/src/cmd/acme
+.SH SEE ALSO
+.IR rio (1),
+.IR acme (1),
+.IR cons (3).
diff --git a/sys/man/4/archfs b/sys/man/4/archfs
new file mode 100755
index 000000000..0ba744c58
--- /dev/null
+++ b/sys/man/4/archfs
@@ -0,0 +1,46 @@
+.TH ARCHFS 4
+.SH NAME
+archfs \- mount mkfs-style archive
+.SH SYNOPSIS
+.B archfs
+[
+.B -abcC
+]
+[
+.B -m 
+.I mtpt
+]
+.I archfile
+.SH DESCRIPTION
+.I Archfs
+mounts at
+.I mtpt
+(default
+.BR /mnt/arch )
+a file system presenting the contents of an 
+archive in the format produced by
+the
+.B -a
+flag to
+.IR mkfs (8).
+The
+.BR -a ,
+.BR -b ,
+.BR -c ,
+and
+.B -C
+flags control the flag argument
+to the
+.B mount
+system call
+(see
+.IR bind (2))
+as in the
+.B mount
+command
+(see
+.IR bind (1)).
+.SH SOURCE
+.B /sys/src/cmd/archfs.c
+.SH SEE ALSO
+.IR mkfs (8)
diff --git a/sys/man/4/cdfs b/sys/man/4/cdfs
new file mode 100755
index 000000000..b038f2f3c
--- /dev/null
+++ b/sys/man/4/cdfs
@@ -0,0 +1,261 @@
+.TH CDFS 4
+.SH NAME
+cdfs, cddb \- optical disc (CD, DVD, BD) track reader and writer file system
+.SH SYNOPSIS
+.B cdfs
+[
+.B -d
+.I sddev
+] [
+.B -m
+.I mtpt
+]
+.br
+.B "grep aux/cddb /mnt/cd/ctl | rc
+.br
+.B aux/cddb
+[
+.B -DTt
+] [
+.B -s
+.I server
+]
+.B query
+.I diskid
+.I ntracks
+.I track0id
+.I ...
+.SH DESCRIPTION
+.I Cdfs
+serves a one and a half level directory
+mounted at
+.I mtpt
+(default
+.BR /mnt/cd )
+that provides access to the tracks
+on discs placed in the disc reader or writer
+named by
+.I sddev
+(default
+.BR /dev/sdD0 ,
+see
+.IR sd (3)).
+Any MMC-compliant compact disc (CD), DVD,
+or Blu-ray disc (BD) drive should work.
+On DVDs and BDs, access to data tracks only is implemented.
+.PP
+The top level directory contains one file
+per disc track.
+The files are named
+.IR cNNN ,
+where
+.I c
+is a type character
+.RB ( a
+for audio tracks
+and
+.B d
+for data tracks)
+and
+.I NNN
+is the track number.
+.PP
+If the device can write discs
+and contains a writable disc, the top-level
+directory also contains an empty directory
+.B wd
+and, for CDs only,
+an empty directory
+.BR wa .
+Files created in these directories
+appear in the top-level directory
+as new data or audio tracks, respectively, regardless of name.
+.PP
+At any time, any number of tracks
+may be open for reading or a single track
+may be open for writing.
+Writing a disc track is a quasi-real-time operation:
+the disc writer should be kept saturated with
+new data to avoid buffer underruns,
+but modern drives will be told to cope with underruns transparently.
+To ensure saturation, copying from a file system
+stored on local disk or memory is recommended.
+.PP
+To fixate a disc (close a recordable disc by writing
+its permanent table of contents), simply
+remove the
+.B wa
+or
+.B wd
+directory.
+The directory removed selects whether
+the disc is fixated as an audio or data disc;
+since each track carries its own type information,
+very few readers care which fixation type was used.
+Rewritable discs do not require fixation.
+.PP
+The top level directory
+also contains a
+.B ctl
+file, into which control messages
+may be echoed.
+The current control messages are:
+.TF \fLquickblank
+.TP
+.B format
+Format the rewritable disc (\c
+.B -RW
+or
+.BR -RE )
+in the drive
+before initial use.
+.TP
+.B blank
+Blank the entire rewritable disc in the drive.
+.TP
+.B quickblank
+Blank only the table of contents on the rewritable
+disc in the drive.
+.\" .TP
+.\" .B closetracks
+.\" Close any open tracks on the current disc but do not finalize (fixate) the disc.
+.TP
+.B eject
+Eject the disc in the drive.
+.TP
+.B ingest
+Ingest a disc into the drive.
+.TP
+.B speed \fIkbps\fR
+Set the reading and writing speed to use,
+in units of 1,000-bytes-per-second.
+A value of
+.L best
+requests the optimal speed for the current drive and disc.
+CD
+.L 1x
+speed is 154;
+DVD
+.L 1x
+speed is 1350;
+BD
+.L 1x
+speed is 4608.
+Drives may round down the speed to one they support.
+To set reading and writing speeds separately,
+prefix the speeds with
+.B read
+or
+.BR write ,
+as in
+.B speed
+.B write
+.B 8192
+or
+.B speed
+.B read
+.B 16384
+.B write
+.BR 8192.
+Note that most drives reset the reading and writing speed
+each time a new disc is inserted.
+.PD
+.PP
+Reading the
+.B ctl
+file yields information about the drive.
+If the drive contains an audio CD, the first line
+will be an
+.B aux/cddb
+command that can be run to query
+an internet CD database
+to get a table of contents.
+Subsequent lines contain the current and maximum
+reading and writing speeds.
+Additional lines may further describe the current disc.
+.PP
+.I Aux/cddb
+takes 4 optional arguments.
+The
+.B -s
+option makes
+.I aux/cddb
+use
+.I server
+for the query instead of
+.LR freedb.freedb.org .
+The
+.B -D
+option causes the raw database response from the server to be dumped
+to standard output.
+The
+.B -t
+option causes the time of each track to be appended to the normal output.
+.B -T
+is like
+.B -t
+but prints a final line with the total time.
+.SH EXAMPLES
+Backup to a BD-R disc:
+.br
+.ne 3
+.IP
+.EX
+9fs boot
+cdfs
+tar cf /mnt/cd/wd/x /n/boot
+.EE
+.br
+.ne 3
+.PP
+Copy the audio tracks from a CD:
+.IP
+.EX
+cdfs -d /dev/sd05
+mkdir /tmp/songs
+cp /mnt/cd/a* /tmp/songs
+.EE
+.PP
+Copy the tracks onto a blank CD inserted in the drive,
+and then fixate the disk as an audio CD.
+.IP
+.EX
+cp /tmp/songs/* /mnt/cd/wa
+rm /mnt/cd/wa
+.EE
+.SH SOURCE
+.B /sys/src/cmd/cdfs
+.SH SEE ALSO
+.IR sd (3),
+.I 9660srv
+(in
+.IR dossrv (4)),
+.IR mk9660 (8)
+.PD 0
+.TF "\fLhttp://www.t10.org\fP"
+.TP
+.B http://www.t10.org
+optical disc interface standards
+.PD
+.SH BUGS
+Fixating a BD-R disc records only the first track in the disc's TOC.
+Any other tracks are still there and their data accessible via
+.IR sd (3).
+There's no need to fixate data discs, except to prevent adding new tracks.
+.PP
+Closing a just-written DVD-R track can take minutes
+while the drive burns the unused part of the track reservation
+(for the whole disc).
+Thus only a single DVD-R track can be written on a DVD-R disc;
+use other media if you need more than one track per disc.
+.PP
+There are too many combinations of optical media, each with unique quirks,
+approximately
+the cross-product of these tuples:
+(CD DVD- DVD+ BD),
+(single-layer dual-layer),
+(-ROM -R -RW).
+.PP
+Only MMC-compliant disc readers and writers
+are supported, but it would be easy to add
+support for early CD writers if desired.
diff --git a/sys/man/4/cfs b/sys/man/4/cfs
new file mode 100755
index 000000000..7d466e1e0
--- /dev/null
+++ b/sys/man/4/cfs
@@ -0,0 +1,124 @@
+.TH CFS 4
+.SH NAME
+cfs \- cache file system
+.SH SYNOPSIS
+.B cfs
+.B -s
+.RB [ -dknrS ]
+.RB [ -f
+.IR partition ]
+.PP
+.B cfs
+.B -a
+.I netaddr
+.RB [ -dknrS ]
+.RB [ -f
+.IR partition ]
+.RI [ mtpt ]
+.PP
+.B cfs
+.B -F
+.I srvfile
+.RB [ -dknrS ]
+.RB [ -f
+.IR partition ]
+.RI [ mtpt ]
+.SH DESCRIPTION
+.I Cfs
+is a user-level file server that caches data from remote
+files onto a local disk.
+It is normally started by the kernel at boot time, though users may start
+it manually.
+.I Cfs
+is interposed between the kernel and a network connection to a
+remote file server to improve the
+efficiency of access across slow network connections such as modem
+lines.
+On each open of a file
+.I cfs
+checks the consistency of cached information and discards any old
+information for that file.
+.PP
+.I Cfs
+mounts onto
+.I mtpt
+(default
+.BR / )
+after connecting to the file server.
+.PP
+The options are:
+.TF -
+.PD
+.TP
+.BI "a " netaddr
+dial the destination
+.I netaddr
+to connect to a remote file server.
+Exclusive with
+.BR -F .
+.TP
+.B d
+turn on debugging.
+.TP
+.BI "f " partition
+use file
+.I partition
+as the cache disk partition.
+.TP
+.BI "F " srvfile
+open
+.I srvfile
+(often a file under
+.BR /srv )
+to connect to a remote file server.
+Exclusive with
+.BR -a .
+.TP
+.B k
+keep cache contents even if they might have come from a different server.
+.I Cfs
+will obey
+.B -r
+even if
+.B -k
+is given.
+.TP
+.B n
+mount the remote file server without authentication;
+often useful with
+.BR -F .
+.TP
+.B r
+reformat the cache disk partition.
+.TP
+.B s
+the connection to the remote file server is on file
+descriptors 0 and 1.
+.TP
+.B S
+turn on statistics gathering.  A file called
+.B cfsctl
+at the root of the caching file system can be read to get
+statistics concerning number of calls/bytes on client and server
+sides and latencies.
+.PP
+All 9P messages except
+.BR read ,
+.BR clone ,
+and
+.B walk
+(see
+.IR intro (5))
+are passed through
+.I cfs
+unchanged to the remote server.
+If possible, a
+.B read
+is satisfied by cached data.
+Otherwise, the file server is queried for any missing data.
+.SH FILES
+.TP
+.B /dev/sdC0/cache
+Default file used for storing cached data.
+.SH SOURCE
+.B /sys/src/cmd/cfs
diff --git a/sys/man/4/cifs b/sys/man/4/cifs
new file mode 100755
index 000000000..f53cf1f1b
--- /dev/null
+++ b/sys/man/4/cifs
@@ -0,0 +1,188 @@
+.TH CIFS 4
+.SH NAME
+cifs - Microsoft™ Windows network filesystem client
+.SH SYNOPSIS
+.B cifs
+[
+.B -bdDiv
+] [
+.B -a
+.I auth-method
+] [
+.B -s
+.I srvname
+] [
+.B -n
+.I called-name
+] [
+.B -k
+.I keyparam
+] [
+.B -m
+.I mntpnt
+]
+.I host
+[
+.I share ...
+]
+.SH DESCRIPTION
+.I Cifs
+translates between Microsoft's file-sharing protocol
+(a.k.a. CIFS or SMB) and 9P, allowing Plan9 clients to mount file systems
+(shares or trees in MS terminology) published by such servers.
+.PP
+The root of the mounted directory contains one subdirectory per share,
+always named in lower case, and a few virtual files of mixed case which
+give additional server, session, share, and user information.
+The arguments are:
+.TF "-a\fI auth-method"
+.PD
+.TP
+.BI -a " auth-method"
+.I Cifs
+authenticates using
+.L BNTLM
+by default, but alternative strategies may be
+selected using this option.
+.I Cifs
+eschews cleartext authentication, however
+it may be enabled with the
+.L plain
+auth method.
+The list of currently-supported methods is printed
+if no method name is supplied.
+.IP
+.I "Windows server 2003"
+requires the
+.B BNTLMv2
+method by default, though it can be configured to be more flexible.
+.TP
+.B -b
+Enable file ownership resolution in
+.IR stat (2)
+calls.
+This requires an open and close per file and thus will slow
+.I cifs
+considerably; its use is not recommended.
+.TP
+.B -d
+CIFS packet debug.
+.TP
+.B -D
+9P request debug.
+.TP
+.BI -k " keyparam"
+lists extra parameters which will be passed to
+.IR factotum (4)
+to select a specific key.
+The remote servers's domain is always included in the keyspec,
+under the assumption
+that all servers in a Windows domain share an authentication domain;
+thus
+.I cifs
+expects keys in
+.I factotum
+of the form:
+.RS
+.IP
+.EX
+key proto=pass dom=THEIR-DOMAIN service=cifs
+	user=MY-USERNAME !password=XYZZY
+.EE
+.RE
+.TP
+.BI -m " mntpnt"
+set the mount point for the remote filesystem;
+the default is
+.BI /n/ host.
+.TP
+.BI -n " called-name"
+The CIFS protocol requires clients to know the NetBios name of the
+server they are attaching to, the
+.IR Icalled-name .
+If this is not specified on the command line,
+.I cifs
+attempts to discover this name from the remote server.
+If this fails it will then try
+.IR host ,
+and finally it will try the name
+.LR *SMBSERVER .
+.TP
+.BI -s " srvname"
+post the service as
+.BI /srv/ srvname.
+.TP
+.I host
+The address of the remote server to connect to.
+.TP
+.I share
+A list of share names to attach on the remote server; if none is given,
+.I cifs
+will attempt to attach all shares published by the remote host.
+.SS "Synthetic Files"
+Several synthetic files appear in the root of the mounted filesystem:
+.TF Workstations
+.PD
+.TP
+.B Shares
+Contains a list of the currently attached shares,
+with fields giving the share name,  disk free space / capacity, the share type,
+and a descriptive comment from the server.
+.TP
+.B Connection
+Contains the username used for authentication,
+server's called name, server's domain,
+server's OS, the time slip between the local host and the server,
+the Maximum Transfer Unit (MTU) the server requested, and optionally a flag
+indicating only guest access has been granted.
+The second line contains a list of capabilities offered by the server which is
+mainly of use for debugging
+.IR cifs .
+.TP
+.B Users
+Each line contains a user's name, the user's full name,
+and a descriptive comment.
+.TP
+.B Groups
+Each line gives a group's name, and a list of the names of the users who
+are members of that group.
+.TP
+.B Sessions
+Lists the users authenticated, the client machine's NetBios name or IP address,
+the time since the connection was established,
+and the time for which the connection has been idle.
+.TP
+.B Domains
+One line per domain giving the domain name and a descriptive comment.
+.TP
+.B Workstations
+One line per domain giving the domain name and a descriptive comment,
+the version number of the OS it is running, and comma-separated list of flags
+giving the features of that OS.
+.TP
+.B Dfsroot
+Top level DFS routing giving the DFS link type, time to live of the data,
+proximity of the server, the Netbios or DNS name and
+a physical path or a machine that this maps to.
+.IP
+DNS paths are usually assigned dynamicially as a form of load balancing.
+.SH SOURCE
+.B /sys/src/cmd/cifs
+.SH SEE ALSO
+.IR factotum (4),
+.IR aquarela (8)
+.SH BUGS
+NetApp Filer compatibility has not yet been tested; there may not be any.
+.PP
+DFS support is unfinished.
+.PP
+Kerberos authentication is unfinished.
+.PP
+NetBios name resolution is not supported, though it is now rarely used.
+.PP
+.I Cifs
+has only been tested against
+.IR aquarela (8),
+Windows 95, NT4.0sp6,
+Windows server 2003, WinXP pro, Samba 3.0, and Samba 2.0 (Pluto VideoSpace).
+No support is attempted for servers predating NT 4.0.
diff --git a/sys/man/4/consolefs b/sys/man/4/consolefs
new file mode 100755
index 000000000..104da9021
--- /dev/null
+++ b/sys/man/4/consolefs
@@ -0,0 +1,253 @@
+.TH CONSOLEFS 4
+.SH NAME
+consolefs, C, clog  \- file system for console access
+.SH SYNOPSIS
+.B aux/consolefs
+[
+.B -m
+.I mntpt
+] [
+.B -c
+.I consoledb
+]
+.PP
+.B C
+.I system
+.PP
+.B aux/clog
+console log
+.I system
+.SH DESCRIPTION
+To ease administration of multiple machines one might attach
+many serial console lines to a single computer.
+.I Consolefs
+is a file system that lets multiple users simultaneously access
+these console lines.
+The consoles and permissions to access them are defined in the
+file
+.I consoledb
+(default
+.BR /lib/ndb/consoledb ).
+The format of
+.I consoledb
+is the same as that of other
+.B /lib/ndb
+files,
+.IR ndb (6).
+Consoles are defined by entries of the form:
+.PP
+.EX
+	console=dirty dev=/dev/eia205
+		uid=bignose
+		gid=support
+		speed=56200
+		cronly=
+.EE
+.PP
+Each
+.IR console / dev
+pair represents the name of a console and the device
+associated with it.
+.I Consolefs
+presents a single level directory with up to three files
+per console:
+.IR console ,
+.IB console ctl\f1,
+and
+.IB console stat\f1.
+Writes of
+.I console
+are equivalent to writes of
+.I dev
+and reads and writes of
+.IB console ctl
+and 
+.IB console stat
+are equivalent to reads and writes of
+.IB dev ctl
+and
+.IB dev stat
+respectively.
+.IB Console ctl
+and
+.IB console stat
+will not exist if the underlying
+.I dev
+does not provide them.
+.I Consolefs
+broadcasts anything it reads from
+.I dev
+to all readers of
+.IR console .
+Therefore, many users can
+.IR con (1)
+to a 
+.IR console ,
+see all output, and enter commands.
+.PP
+The
+.I cronly=
+attribute causes newlines typed by the user to be sent to
+the console as returns.
+The
+.I speed=x
+attribute/value pair specifies a bit rate for the
+console.  The default is 9600 baud.
+The
+.I openondemand=
+attribute causes the console device
+.RI ( dev )
+to be opened only when the corresponding
+.IB mntpt / console
+file is open.
+.PP
+Access to the console is controlled by the
+.I uid
+and
+.I gid
+attributes/value pairs.
+The uid values are user account names.
+The gid values are the names of groups defined in
+.I consolefs
+by entries of the form:
+.PP
+.EX
+	group=support
+		uid=bob
+		uid=carol
+		uid=ted
+		uid=alice
+.EE
+.PP
+Groups are used to avoid excessive typing.  Using
+.I gid=x
+is equivalent to including a
+.I uid=y
+for each user
+.I y
+that is a member of
+.IR x .
+.PP
+To keep users from inadvertently interfering with one another,
+notification is broadcast to all readers whenever a user
+opens or closes
+.IR name .
+For example, if user
+.B boris
+opens a console that users
+.B vlad
+and
+.B barney
+have already opened, all will read the message:
+.PP
+.EX
+	[+boris, vlad, barney]
+.EE
+.PP
+If
+.B vlad
+then closes,
+.B boris
+and 
+.B barney
+will read:
+.PP
+.EX
+	[-vlad, boris, barney]
+.EE
+.PP
+.I Consolefs
+posts the client end of its 9P channel in
+.BR /srv/consolefs
+and mounts this locally in
+.I mntpt
+(default
+.BR /mnt/consoles );
+remote clients must
+.B mount
+(see
+.IR bind (1))
+this file to see the consoles.
+.PP
+The
+.IR rc (1)
+script
+.B C
+automates this procedure.
+It uses
+.IR import (4)
+to connect to
+.B /mnt/consoles
+on the machine connected to all the consoles, then uses
+.IR con (1)
+to connect to the console of the machine
+.IR system.
+The script must be edited at installation
+by the local administration to identify the
+system that holds
+.BR /mnt/consoles .
+.PP
+.I Aux/clog
+opens the file
+.I console
+and writes every line read from it, prefixed
+by the ASCII time to the file
+.IR log .
+.PP
+An example of 2 consoles complete with console logging is:
+.IP
+.EX
+% cat /lib/ndb/consoledb
+group=sys
+	uid=glenda
+console=bootes dev=/dev/eia0 gid=sys
+console=fornax dev=/dev/eia1 gid=sys
+% aux/consolefs
+% ls -p /mnt/consoles
+bootes
+bootesctl
+fornax
+fornaxctl
+% clog /mnt/consoles/fornax /sys/log/fornax &
+% clog /mnt/consoles/bootes /sys/log/bootes &
+.EE
+.PP
+The console server's default name space must 
+mount the consoles for 
+.I C
+to import.
+This can be arranged by adding
+.IP
+.EX
+mount /srv/consoles /mnt/consoles
+.EE
+.LP
+to
+.BR /lib/namespace.$sysname .
+.SH FILES
+.TF /lib/ndb/consoledb
+.TP
+.B /srv/consoles
+Client end of pipe to server.
+.TP
+.B /mnt/consoles
+Default mount point.
+.TP
+.B /lib/ndb/consoledb
+Default user database.
+.SH SOURCE
+.B /sys/src/cmd/aux/consolefs.c
+.br
+.B /rc/bin/C
+.br
+.B /sys/src/cmd/aux/clog.c
+.SH BUGS
+.PP
+Changing the gid's or uid's while
+.I consolefs
+is running
+is detected by
+.IR consolefs .
+However, to add new consoles
+one must restart
+.IR consolefs .
diff --git a/sys/man/4/cwfs b/sys/man/4/cwfs
new file mode 100755
index 000000000..6bf6c7b27
--- /dev/null
+++ b/sys/man/4/cwfs
@@ -0,0 +1,317 @@
+.TH CWFS 4
+.SH NAME
+cwfs \- cached-worm file server, dump
+.SH SYNOPSIS
+.B cwfs
+[
+.B -cf
+] [
+.B -a
+.I announce-string
+] ... [
+.B -m
+.I device-map
+]
+.I config-device
+.SH DESCRIPTION
+.I Cwfs
+is a cached-worm file server that runs
+as a user-mode program and can
+maintain file systems created by
+.IR fs (4),
+the original Plan 9 file server
+that had its own kernel and operated
+a standalone system with disks and
+optical-disc jukebox attached.
+Unlike
+.IR fs (4),
+which could only accept 9P connections over IL/IPv4 on Ethernets
+(or over Datakit and Cyclones, long ago),
+.I cwfs
+accepts 9P connections over any network medium and protocol
+that it can announce on,
+by default TCP (over IPv4 or IPv6).
+Given suitable 9P clients,
+one could even run 9P over
+.IR aan (8)
+or
+.IR tls (3).
+.PP
+The stock
+.I cwfs
+implements a 16K file system block size
+and 32-bit disk addresses,
+in order to be compatible with some existing file systems, notably
+.IR emelie 's.
+These parameters can be changed by recompilation.
+.PP
+.I Cwfs
+expects to find the configuration block on
+.IR config-device .
+.PP
+Options are:
+.TF -m
+.TP
+.B -a
+announce on
+.I announce-string
+instead of
+.LR tcp!*!9fs .
+.TP
+.B -c
+use a newer, faster, and incompatible cache-device layout.
+To convert an old file system's cache to the new layout,
+dump the file system, note the last superblock number,
+halt
+.IR cwfs ,
+restart
+.I cwfs
+with
+.BR -cf ,
+.I recover
+the file system, and start
+.I cwfs
+with
+.B -c
+thereafter.
+.TP
+.B -f
+enter the file server's configuration mode
+before starting normal operation.
+.TP
+.B -m
+the file
+.I device-map
+contains a simple device name
+(e.g.,
+.LR w9 )
+and a replacement per line.
+The device name is in the usual
+.I filsys
+notation of
+.IR fsconfig (8).
+The replacement can be the name of an existing file
+(which
+.I cwfs
+will not grow)
+or another such device name.
+For example, the file
+.RS
+.PD
+.IP
+.EX
+w0 /tmp/w0
+h1 w2
+.EE
+.PP
+.PD 0.3v
+would map accesses to device
+.L w0
+to existing file
+.LR /tmp/w0
+and accesses to device
+.L h1
+to device
+.LR w2 ,
+if no file named
+.L w2
+exists.
+.RE
+.PD
+.PP
+The file server normally requires all users except
+.L none
+to provide authentication tickets on each
+.IR attach (5).
+This can be disabled using the
+.B noauth
+configuration command (see
+.IR fsconfig (8)).
+.PP
+The group numbered 9999, normally called
+.BR noworld ,
+is special
+on the file server.  Any user belonging to that group has
+attenuated access privileges.  Specifically, when checking such
+a user's access to files, the file's permission bits are first ANDed
+with 0770 for normal files or 0771 for directories.  The effect is
+to deny world access permissions to
+.B noworld
+users, except
+when walking directories.
+.PP
+The user
+.B none
+is always allowed to attach to
+.B emelie
+without authentication but has minimal permissions.
+.PP
+.B Emelie
+maintains three file systems
+on a combination of disks and
+write-once-read-many (WORM) magneto-optical disks.
+.TP
+.B other
+is a simple disk-based file system similar to
+.IR kfs (4) .
+.TP
+.B main
+is a worm-based file system with a disk-based
+look-aside cache.
+The disk cache holds
+modified worm blocks
+to overcome the write-once property of the worm.
+The cache also holds recently accessed
+non-modified blocks to
+speed up the effective access time of the worm.
+Occasionally
+(usually daily at 5AM) the modified blocks in the
+disk cache are
+.IR dumped .
+At this time,
+traffic to the file system is halted and the
+modified blocks are relabeled to the unwritten
+portion of the worm.
+After the dump,
+the file system traffic is continued and
+the relabeled blocks are copied to the worm by
+a background process.
+.TP
+.B dump
+Each time the main file system is dumped,
+its root is appended to a subdirectory of the dump file system.
+Since the dump file system is not mirrored with a disk
+cache,
+it is read-only.
+The name of the newly added root is created from the date
+of the dump:
+.BI / yyyy / mmdds\f1.
+Here
+.I yyyy
+is the full year,
+.I mm
+is the month number,
+.I dd
+is the day number and
+.I s
+is a sequence number if more than
+one dump is done in a day.
+For the first dump,
+.I s
+is null.
+For the subsequent dumps
+.I s
+is 1, 2, 3, etc.
+.sp
+The root of the main file system
+that is frozen on the first dump
+of March 1, 1992
+will be named
+.B /1992/0301/
+in the dump file system.
+.SS "Changes from fs(4)"
+.IR fs (4)'s
+IP configuration is ignored and the underlying system's is used.
+.PP
+Various other
+.IR fs (4)
+commands have been omitted since they (or equivalents) can now be
+executed directly on the underlying CPU server,
+notably
+.I date
+and
+.I passwd
+(see
+.IR auth/wrkey ).
+.PP
+.IR fs (4)'s
+device names
+.L h
+for IDE disks and
+.L m
+for Marvell SATA disks are not supported; use
+.B -m
+to map wren devices to appropriate names under
+.BR /dev/sd* .
+.PP
+The file server kernel seems to have scanned PCI buses
+in reverse order from the other Plan 9 kernels,
+so systems with multiple SCSI cards may find controller
+numbering reversed.
+.B -m
+can be used to compensate for this if you don't want to change
+.I filsys
+declarations.
+.PP
+The file server kernel's
+.I config
+field in NVRAM was overloaded in recent times to hold a
+.IR secstore (1)
+key for the CPU hostowner.
+Since
+.I cwfs
+runs on a CPU kernel,
+the location of its configuration block must be supplied on the command line.
+.PP
+Disk labels are now implemented for
+.B l
+devices.
+At the first access of a side,
+.I cwfs
+will attempt to read the label and verify that it has the correct side
+number and byte order; if either is wrong, it will issue a warning.
+If the label cannot be read,
+.I cwfs
+will attempt to write a new label.
+.SH EXAMPLES
+Place the root of the
+.B dump
+file system on
+.B /n/dump
+and show the modified times of the MIPS C compiler
+over all dumps in February, 1992:
+.IP
+.EX
+cwfs w0
+9fs dump
+ls -l /n/dump/1992/02??/mips/bin/vc
+.EE
+.PP
+To get only one line of output for each version of the compiler:
+.IP
+.EX
+ls -lp /n/dump/1992/02??/mips/bin/vc | uniq
+.EE
+.SH SOURCE
+.B /sys/src/cmd/cwfs
+.SH SEE ALSO
+.IR yesterday (1),
+.IR fs (3),
+.IR sd (3),
+.IR fossil (4),
+.IR fs (4),
+.IR srv (4),
+.IR fs (8),
+.IR fsconfig (8)
+.br
+Sean Quinlan,
+``A Cached WORM File System'',
+.I
+Software \- Practice and Experience,
+December, 1991
+.br
+Ken Thompson,
+Geoff Collyer,
+``The 64-bit Standalone Plan 9 File Server''
+.SH BUGS
+For the moment,
+the file server serves both the old (9P1) and new (9P2000) versions of 9P,
+deciding which to serve by sniffing the first packet on each connection.
+.PP
+File system block size and disk address size (32- or 64-bit) are fixed
+at compilation time, and this is not easily changed.
+.PP
+.I Cwfs
+is probably not the right choice of file server for new file systems.
+It's intended to cope with existing file systems on optical jukeboxes
+or images thereof.
diff --git a/sys/man/4/dossrv b/sys/man/4/dossrv
new file mode 100755
index 000000000..8bfbf5414
--- /dev/null
+++ b/sys/man/4/dossrv
@@ -0,0 +1,221 @@
+.TH DOSSRV 4
+.SH NAME
+dossrv, 9660srv, a:, b:, c:, d:, 9fat:, dosmnt, eject \- DOS and ISO9660 file systems
+.SH SYNOPSIS
+.B dossrv
+[
+.B -rsv
+] [
+.B -f
+.I file
+] [
+.I service
+]
+.PP
+.B 9660srv
+[
+.B -9Jsv
+] [
+.B -c
+.I clusters
+] [
+.B -f
+.I file
+] [
+.I service
+]
+.PP
+.B a:
+.PP
+.B b:
+.PP
+.B c:
+.PP
+.B 9fat:
+.PP
+.B dosmnt
+.I n
+.I mtpt
+.PP
+.B eject
+[
+.I n
+]
+.SH DESCRIPTION
+.I Dossrv
+is a file server that interprets DOS file systems.
+A single instance of
+.I dossrv
+can provide access to multiple DOS disks simultaneously.
+.PP
+.I Dossrv
+posts a file descriptor named
+.I service
+(default
+.BR dos )
+in the
+.B /srv
+directory.
+To access the DOS file system on a device, use
+.B mount
+with the
+.I spec
+argument
+(see
+.IR bind (1))
+the name of the file holding raw DOS file system, typically the disk.
+If
+.I spec
+is undefined in the
+.BR mount ,
+.I dossrv
+will use
+.I file
+as the default name for the device holding the DOS system.
+.PP
+Normally
+.I dossrv
+creates a pipe to act as the communications channel between
+itself and its clients.
+The
+.B -s
+flag instructs
+.I dossrv
+to use its standard input and output instead.
+The kernels use this option if they are booting from a DOS disk.
+This flag also prevents the creation of an explicit service file in
+.BR /srv .
+.PP
+The
+.B -v
+flag causes verbose output for debugging, while
+the
+.B -r
+flag makes the file system read-only.
+.PP
+The shell script
+.I a:
+contains
+.IP
+.EX
+unmount /n/a: >[2] /dev/null
+mount -c /srv/dos /n/a: /dev/fd0disk
+.EE
+.LP
+and is therefore a shorthand for mounting a floppy disk in drive A.
+The scripts
+.I b:
+and
+.I dosmnt
+are similar,
+mounting the second floppy disk
+and the
+.IR n th
+non-floppy DOS partition,
+respectively.
+.I C:
+and
+.I d:
+call
+.I dosmnt
+in an attempt to name the drives in
+the same order that Microsoft operating systems do.
+.I 9fat:
+provides access to the FAT component of the Plan 9 partition (see
+.IR prep (8)).
+.PP
+The file attribute flags used by the DOS file system
+do not map directly to those used by Plan 9.
+Since there is no concept of user or group,
+permission changes via
+.B wstat
+(see
+.IR stat (2))
+will fail unless the same (read, write, execute) permissions
+are specified for user, group, and other.
+For example, removing write permission in Plan 9
+corresponds to setting the read-only
+attribute in the DOS file system.
+Most of the other DOS attributes
+are not accessible.
+.PP
+Setting the exclusive use flag (DMEXCL)
+in Plan 9 corresponds to setting the
+system use attribute in the DOS file system.
+Such files are not actually restricted to exclusive use,
+but do merit special treatment that
+helps in the creation of boot disks:
+when 
+.I dossrv
+allocates a new block for such a file
+(caused, say, by a write that fills the file's
+last allocated block), it succeeds only if it can
+arrange for the file to be stored
+contiguously on disk.
+.PP
+Since other operating systems do not
+guarantee that system files are laid
+out contiguously, the DMAPPEND mode
+bit is set in file stat information
+only when the file is currently contiguous.
+Attempts to set the DMAPPEND mode bit
+explicitly will cause 
+.I dossrv
+to try to make the file contiguous,
+succeeding only if this is possible.
+.PP
+.I 9660srv
+is similar to
+.I dossrv
+in specification, except that it interprets ISO9660 CD-ROM
+file systems instead of DOS file systems.
+Some CDs contain multiple directory trees describing
+the same set of files.
+.IR 9660srv 's
+first choice in such a case is a standard ISO9660 tree
+with Plan 9 system use fields;
+the second choice is a Microsoft ``Joliet'' tree, which
+allows long file names and Unicode characters;
+the third choice is a standard ISO9660 or High Sierra tree.
+The
+.B -9
+flag causes
+.I 9660srv
+to ignore the Plan 9 system use fields,
+while the
+.B -J
+flag causes it to
+ignore the Joliet tree.
+The
+.B -c
+option sets the size of the RAM cache to
+.I clusters
+clusters of 128KB.
+The default
+.I clusters
+is 16,
+but a value of 5600 will cache an entire CD incrementally.
+.PP
+If the floppy drive has an ejection motor,
+.I eject
+will spit out the floppy from drive
+.IR n ,
+default 0.
+.SH EXAMPLE
+Mount a floppy disk with a DOS file system on it.
+.IP
+.EX
+a:
+.EE
+.SH "SEE ALSO"
+.IR kfs (4)
+.SH SOURCE
+.B /sys/src/cmd/dossrv
+.br
+.B /sys/src/cmd/9660srv
+.br
+.B /rc/bin/eject
+.SH BUGS
+The overloading of the semantics of
+the DMEXCL and DMAPPEND
+bits can be confusing.
diff --git a/sys/man/4/execnet b/sys/man/4/execnet
new file mode 100755
index 000000000..9375a14b0
--- /dev/null
+++ b/sys/man/4/execnet
@@ -0,0 +1,67 @@
+.TH EXECNET 4
+.SH NAME
+execnet \- network interface to program execution
+.SH SYNOPSIS
+.B execnet
+[
+.B -n
+.I name
+]
+[
+.B netdir
+]
+.SH DESCRIPTION
+.I Execnet
+presents a network protocol directory
+(see, for example,
+.IR ip (3))
+called
+.IB netdir / name
+(default
+.BR /net/exec ).
+.PP
+Once the protocol directory exists, dialing
+(see
+.IR dial (2))
+strings of
+the form
+.IB name ! cmd
+will connect to a newly executed instance of
+.IR cmd .
+.SH EXAMPLE
+.I Execnet
+can be used to connect to instances of
+.IR u9fs (4)
+running on other hosts:
+.EX
+    g% execnet
+    g% srv -m 'exec!ssh ny start-u9fs' ny /n/ny
+.EE
+This example assumes that the remote command
+.B start-u9fs
+executed on
+.B ny
+will start
+.I u9fs
+appropriately.
+For example, it might be:
+.EX
+    ny% cat start-u9fs
+    #!/bin/sh
+
+    u9fs -na none -u $USER -l $HOME/tmp/u9fs.log
+    ny%
+.EE
+See the 
+.IR u9fs (4)
+man page for more information.
+.SH SOURCE
+.B /sys/src/cmd/execnet
+.SH "SEE ALSO
+.IR dial (2),
+.IR ip (3),
+.IR u9fs (4)
+.SH BUGS
+Almost certainly:
+.IR execnet
+has only been tested as in the example shown.
diff --git a/sys/man/4/exportfs b/sys/man/4/exportfs
new file mode 100755
index 000000000..649e0444b
--- /dev/null
+++ b/sys/man/4/exportfs
@@ -0,0 +1,257 @@
+.TH EXPORTFS 4
+.SH NAME
+exportfs, srvfs \- network file server plumbing
+.SH SYNOPSIS
+.B exportfs
+[
+.I options
+]
+.PP
+.B srvfs
+[
+.B -dR
+]
+[
+.B -p
+.I perm
+]
+[
+.B -P
+.I patternfile
+] [
+.B -e
+.I exportprog
+]
+.I name
+.I path
+.SH DESCRIPTION
+.I Exportfs
+is a user level file server that allows Plan 9 compute servers, rather
+than file servers, to export portions of a name space across networks.
+The service is started either by the
+.IR cpu (1)
+command or by a network listener process.  An initial protocol
+establishes a root directory for the exported name space.
+The
+connection to
+.I exportfs
+is then mounted, typically on
+.BR /mnt/term .
+.I Exportfs
+then acts as a relay file server: operations in the imported file
+tree are executed on the remote server and the results returned.  This
+gives the appearance of exporting a name space from a remote machine
+into a local file tree.
+.PP
+The options are:
+.TF "-A \fIaddress"
+.PD
+.TP
+.B -A \fIaddress
+Use the network
+.I address
+to announce
+.IR aan (8)
+connections,
+if requested by the initial protocol.
+.TP
+.B -a
+Authenticate the user with the
+.I p9any
+protocol before running the regular
+.I exportfs
+session; used when 
+.I exportfs
+is invoked to handle an incoming network connection.
+.I Exportfs
+creates a new name space for each connection, using
+.B /lib/namespace
+by default (see
+.IR namespace (6)).
+.TP
+.B -B \fIaddress
+Dial
+.IR address ,
+authenticate as a
+.I p9any
+client, and then
+serve that network connection.
+Requires setting the root of the name space with 
+.B -r
+or
+.BR -s .
+The remote system should run
+.B import
+.B -B
+to handle the call.
+See
+.IR import (4)
+for an example.
+.TP
+.B -d -f \fIdbgfile
+Log all 9P traffic to
+.I dbgfile
+(default
+.BR /tmp/exportdb ).
+.TP
+.B -e '\fIenc auth\fL'
+Set the encryption and authentication algorithms to use for
+encrypting the wire traffic (see
+.IR ssl (3)).
+The defaults are
+.B rc4_256
+and
+.BR sha1 .
+.TP
+.B -m \fImsize
+Set the maximum message size that 
+.I exportfs
+should offer to send (see
+.IR version (5));
+this helps tunneled
+9P connections to avoid unnecessary fragmentation.
+.TP
+.B -N \fInsfile
+Serve the name space described by
+.IR nsfile .
+.TP
+.B -n
+Disallow mounts by user
+.BR none .
+.TP
+.B -P \fIpatternfile
+Restrict the set of exported files.
+.I Patternfile
+contains one regular expression per line,
+to be matched against path names
+relative to the current working directory
+and starting with
+.BR ./ .
+For a file to be exported, all lines with a prefix
+.B +
+must match and all those with prefix
+.B -
+must not match.
+.TP
+.B -R
+Make the served name space read only.
+.TP
+.B -r \fIroot
+Bypass the initial protocol, serving the name space rooted at
+.IR root .
+.TP
+.B -S \fIservice
+bypass the initial protocol, serving the result of mounting
+.IR service .
+A separate mount is used for each
+.IR attach (5)
+message,
+to correctly handle servers in which each mount
+corresponds to a different client
+.IR e.g. , (
+.IR rio (4)).
+.TP
+.B -s
+equivalent to
+.B -r
+.BR / ;
+kept for compatibility.
+.PD
+.PP
+The
+.B cpu
+command uses
+.I exportfs
+to serve device files in the terminal.  The
+.IR import (4)
+command calls
+.I exportfs
+on a remote machine, permitting users to access arbitrary pieces of
+name space on other systems.
+.PP
+Because the kernel disallows reads and writes on mounted pipes
+(as might be found in
+.BR /srv ),
+.I exportfs
+calls itself (with appropriate
+.B -m
+and
+.B -S 
+options) to simulate reads and writes on such files.
+.PP
+.I Srvfs
+invokes
+.I exportprog
+(default
+.BR /bin/exportfs )
+to create a mountable file system from a name space
+and posts it at
+.BI /srv/ name ,
+which is created with mode
+.I perm
+(default 0600).
+The name space is the directory tree rooted at 
+.IR path .
+The
+.BR -d ,
+.BR -P ,
+and
+.B -R
+options, if present, are relayed to
+.IR exportprog .
+.SH EXAMPLES
+To export the archive of one user for one month, except for secrets,
+.IP
+.EX
+cd /n/dump
+echo '+ ^\e.(/2003(/10..(/usr(/glenda/?)?)?)?)?' > /tmp/pattern
+echo '- \e.(aes|pgp)$' >> /tmp/pattern
+exportfs -P /tmp/pattern
+.EE
+.LP
+Use
+.I srvfs
+to enable mounting of an FTP file system (see
+.IR ftpfs (4))
+in several windows, 
+or to publish a
+.B /proc
+(see
+.IR proc (3))
+with a broken process so a remote person may debug the program:
+.IP
+.EX
+srvfs ftp /n/ftp
+srvfs broke /mnt/term/proc
+.EE
+.LP
+Use 
+.I srvfs
+to obtain a copy of a service to be manipulated directly
+by a user program like
+.IR nfsserver (8):
+.IP
+.EX
+srvfs nfs.boot /srv/boot
+aux/nfsserver -f /srv/nfs.boot
+.EE
+.LP
+Use
+.I srvfs
+to spy on all accesses to a particular subtree:
+.IP
+.EX
+srvfs -d spy /
+tail -f /tmp/exportdb &
+mount /srv/spy /n/spy
+cd /n/spy; ls
+.EE
+.SH SOURCE
+.B /sys/src/cmd/exportfs
+.br
+.B /sys/src/cmd/srvfs.c
+.SH SEE ALSO
+.IR dial (2),
+.IR import (4),
+.IR aan (8),
+.IR listen (8)
diff --git a/sys/man/4/ext2srv b/sys/man/4/ext2srv
new file mode 100755
index 000000000..6dcb950fb
--- /dev/null
+++ b/sys/man/4/ext2srv
@@ -0,0 +1,110 @@
+.TH EXT2SRV 4
+.SH NAME
+ext2srv \- ext2 file system
+.SH SYNOPSIS
+.B ext2srv
+[
+.B -vrs
+] [
+.B -f
+.I file
+] [
+.B -p
+.I passwd
+] [
+.B -g
+.I group
+] [
+.I service
+]
+.SH DESCRIPTION
+.I Ext2srv
+is a file server that interprets the Linux Second Extended File System.
+A single instance of
+.I ext2srv
+can provide access to multiple ext2 partitions simultaneously.
+.PP
+.I Ext2srv
+posts a file descriptor named
+.I service
+(default
+.BR ext2 )
+in the
+.B /srv
+directory.
+To access an ext2 file system on a device, use
+.B mount
+with the
+.I spec
+argument
+(see
+.IR bind (1))
+the name of the file holding the raw ext2 file system, typically the disk or partition.
+If
+.I spec
+is undefined in the
+.BR mount ,
+.I ext2srv
+will use
+.I file
+as the default name for the device holding the file system.
+.PP
+Normally
+.I ext2srv
+creates a pipe to act as the communications channel between
+itself and its clients.
+The
+.B -s
+flag instructs
+.I ext2srv
+to use its standard input and output instead.
+This flag also prevents the creation of an explicit service file in
+.BR /srv .
+.PP
+The
+.B -v
+flag causes verbose output for debugging, while
+the
+.B -r
+flag (recommended) makes the file system read-only.
+The optional
+.B -p
+and
+.B -g
+flags specify Unix-format password (respectively group) files
+that give the mapping between the numeric user- and group-ID
+numbers in the ext2 file system and the strings reported by Plan 9 status
+inquiries.
+.PP
+There is no authentication or permission checking.
+Anyone who can access the ext2 file system will have full access
+to all its files, including write access if
+.I ext2srv
+is not started with the
+.B -r
+flag, irrespective of file ownership and permission flags.
+.PP
+Some file system state is cached in memory, and may
+be flushed only when the file system is unmounted.
+Therefore if
+.I ext2srv
+is stopped or the machine is rebooted while an ext2 file system
+is still mounted,
+the superblock on the device will have been marked `not valid'
+(unless the
+.B -r
+flag was used),
+and a
+.I fsck
+will be required before that file system may be mounted again.
+.SH BUGS
+There is no authentication or permission checking.
+The implementation has not tracked any changes to the ext2
+specification since it was written.
+There may be other bugs.
+It is advisable to use
+.I ext2srv
+in read-only mode whenever possible.
+.SH AUTHOR
+Bodet Laurent (bl@mime.univ-paris8.fr),
+with later updates by Russ Cox and Richard Miller.
diff --git a/sys/man/4/factotum b/sys/man/4/factotum
new file mode 100755
index 000000000..a66f19a4c
--- /dev/null
+++ b/sys/man/4/factotum
@@ -0,0 +1,728 @@
+.TH FACTOTUM 4
+.SH NAME
+factotum, fgui \- authentication agent
+.SH SYNOPSIS
+.B auth/factotum
+[
+.B -DdknpuS
+] [
+.B -a asaddr
+] [
+.B -s
+.I srvname
+] [
+.B -m
+.I mtpt
+]
+.PP
+.B auth/factotum
+.B -g
+.IB attribute = value
+.B ...
+.IB attribute ?
+.B ...
+.PP
+.B auth/fgui
+.SH DESCRIPTION
+.I Factotum
+is a user-level file system that
+acts as the authentication agent for a user.
+It does so by managing a set of
+.IR keys .
+A key is a collection of information used to authenticate a particular action.
+Stored as a list of
+.IB attribute = value
+pairs, a key typically contains a user, an authentication domain, a protocol, and
+some secret data.
+.PP
+.I Factotum
+presents a two level directory.  The first
+level contains a single directory
+.BR factotum ,
+which in turn contains:
+.TF needkey
+.TP
+.B rpc
+each open represents a new private channel to
+.I factotum
+.TP
+.B proto
+when read lists the protocols available
+.TP
+.B confirm
+for confiming the use of key
+.TP
+.B needkey
+allows external programs to control the addition of new keys
+.TP
+.B log
+a log of actions
+.TP
+.B ctl
+for maintaining keys; when read, it returns a list of keys.
+For secret attributes, only the attribute name follow by a
+.L ?
+is returned.
+.PD
+.PP
+In any authentication, the caller typically acts as a client
+and the callee as a server.  The server determines
+the authentication domain, sometimes after a negotiation with
+the client.  Authentication always requires the client to
+prove its identity to the server.  Under some protocols, the
+authentication is mutual.
+Proof is accomplished using secret information kept by factotum
+in conjunction with a cryptographic protocol.
+.PP
+.I Factotum
+can act in the role of client for any process possessing the
+same user id as it.  For select protocols such as
+.B p9sk1
+it can also act as a client for other processes provided
+its user id may speak for the other process' user id (see
+.IR authsrv (6)).
+.I Factotum
+can act in the role of server for any process.
+.PP
+.IR Factotum 's
+structure is independent of
+any particular authentication protocol.
+.I Factotum
+supports the following protocols:
+.TF mschap
+.TP
+.B p9any
+a metaprotocol used to negotiate which actual protocol to use.
+.TP
+.B p9sk1
+a Plan 9 shared key protocol described in
+.IR authsrv (6)'s
+``File Service'' section.
+.TP
+.B p9sk2
+a variant of
+.B p9sk1
+described in
+.IR authsrv (6)'s
+``Remote Execution'' section.
+.TP
+.B p9cr
+a Plan 9 protocol that can use either
+.B p9sk1
+keys or SecureID tokens.
+.TP
+.B apop
+the challenge/response protocol used by POP3 mail servers.
+.TP
+.B cram
+the challenge/response protocol also used by POP3 mail servers.
+.TP
+.B chap
+the challenge/response protocols used by PPP and PPTP.
+.TP
+.B mschap
+a proprietary Microsoft protocol also used by PPP and PPTP.
+.TP
+.B rsa
+RSA public key decryption, used by SSH and TLS.
+.TP
+.B pass
+passwords in the clear.
+.TP
+.B vnc
+.IR vnc (1)'s
+challenge/response.
+.TP
+.B wep
+WEP passwords for wireless ethernet cards.
+.PD
+.PP
+The options are:
+.TP
+.B \-a
+supplies the address of the authentication server to use.
+Without this option, it will attempt to find an authentication server by
+querying the connection server, the file
+.BR <mtpt>/ndb ,
+and finally the network database in
+.BR /lib/ndb .
+.TP
+.B \-m
+specifies the mount point to use, by default
+.BR /mnt .
+.TP
+.B \-s
+specifies the service name to use.
+Without this option,
+.I factotum
+does not create a service file in
+.BR /srv .
+.TP
+.B \-D
+turns on 9P tracing, written to standard error.
+.TP
+.B \-d
+turns on debugging, written to standard error.
+.TP
+.B \-g
+causes the agent to prompt for the key, write it
+to the
+.B ctl
+file, and exit.
+The agent will prompt for values for any of the
+attributes ending with a question mark
+.RB ( ? )
+and will append all the supplied
+.I attribute = value
+pairs.  See the section on key templates below.
+.TP
+.B \-n
+don't look for a secstore.
+.TP
+.B \-S
+indicates that the agent is running on a
+CPU server.  On starting, it will attempt to get a
+.B p9sk1
+key from NVRAM using
+.B readnvram
+(see
+.IR authsrv (2)),
+prompting for anything it needs.
+It will never subsequently prompt for a
+key that it doesn't have.
+This option is typically used by
+the kernel at boot time.
+.TP
+.B \-k
+causes the NVRAM to be written.
+It is only valid with the
+.B \-S
+option.
+This option is typically used by
+the kernel at boot time.
+.TP
+.B \-u
+causes the agent to prompt for user
+id and writes it to
+.BR /dev/hostowner .
+It is mutually exclusive with
+.B \-k
+and
+.BR \-S .
+This option is typically used by
+the kernel at boot time.
+.TP
+.B \-p
+causes the agent not to mark itself `private'
+via 
+.IR proc (3),
+so that it can be debugged.
+It is implied by
+.BR \-d .
+.PD
+.PP
+.I Fgui
+is a graphic user interface for confirming key usage and
+entering new keys.  It hides the window in which it starts
+and waits reading requests from
+.B confirm
+and
+.BR needkey .
+For each requests, it unhides itself and waits for
+user input.
+See the sections on key confirmation and key prompting below.
+.SS "Key Tuples
+.PP
+A
+.I "key tuple
+is a space delimited list of 
+.IB attribute = value
+pairs.  An attribute whose name begins with an exclamation point
+.RB ( ! )
+does not appear when reading the
+.B ctl
+file.
+The required attributes depend on the authentication protocol.
+.PP
+.BR P9sk1 ,
+.BR p9sk2 ,
+and
+.BR p9cr
+all require a key with
+.BR proto = p9sk1 ,
+a
+.B dom
+attribute identifying the authentication domain, a
+.B user
+name valid in that domain, and either a
+.B !password
+or
+.B !hex
+attribute specifying the password or hexadecimal secret
+to be used.  Here is an example:
+.PP
+.EX
+    proto=p9sk1 dom=avayalabs.com user=presotto !password=lucent
+.EE
+.PP
+.BR Apop ,
+.BR cram ,
+.BR chap ,
+and
+.BR mschap ,
+require a key with a
+.B proto
+attribute whose value matches the protocol,
+in addition to
+.BR server ,
+.BR user ,
+and
+.B !password
+attributes; 
+e.g.
+.PP
+.EX
+    proto=apop server=mit.edu user=rsc !password=nerdsRus
+.EE
+Vnc is similar but does not require a
+.B user
+attribute.
+.PP
+.B Pass
+requires a key with
+.B proto=pass
+in addition to
+.B user
+and
+.B !password
+attributes; e.g.
+.PP
+.EX
+    proto=pass user=tb !password=does.it.matter
+.EE
+.PP
+.B Rsa
+requires a key with
+.B proto=rsa
+in addition to all the hex attributes defining an RSA key:
+.BR ek ,
+.BR n ,
+.BR !p ,
+.BR !q ,
+.BR !kp ,
+.BR !kq ,
+.BR !c2 ,
+and
+.BR !dk .
+By convention, programs using the RSA protocol also require a
+.B service
+attribute set to
+.BR ssh ,
+.BR sshserve ,
+or
+.BR tls .
+.PP
+.B Wep
+requires a
+.BR key1 ,
+.BR key2 ,
+or
+.BR key3
+set to the password to be used.
+Starting the protocol causes
+.I factotum
+to configure the wireless ethernet card
+.B #l/ether0
+for WEP encryption with the given password.
+.PP
+All keys can have additional attributes that act either as comments
+or as selectors to distinguish them in the
+.IR auth (2)
+library calls.
+.PP
+The factotum owner can use any key stored by factotum.
+Any key may have one or more
+.B owner
+attributes listing the users who can use the key
+as though they were the owner.
+For example, the TLS and SSH host keys on a server
+often have an attribute
+.B owner=*
+to allow any user (and in particular,
+.LR none )
+to run the TLS or SSH server-side protocol.
+.PP
+Any key may have a
+.B role
+attribute for restricting how it can be used.
+If this attribute is missing, the key can be used in any role.
+The possible values are:
+.TP
+.B client
+for authenticating outbound calls
+.TP
+.B server
+for authenticating inbound calls
+.TP
+.B speakfor
+for authenticating processes whose
+user id does not match
+.IR factotum 's.
+.PP
+If a key has a
+.B disabled
+attribute (with any value), the key is not used
+during any protocols.  Factotum automatically marks
+keys with
+.B disabled=by.factotum
+when they fail during certain authentication
+protocols (in particular, the Plan 9 ones).
+.PD
+.PP
+Whenever
+.I factotum
+runs as a server, it must have a
+.B p9sk1
+key in order to communicate with the authentication
+server for validating passwords and challenge/responses of
+other users.
+.SS "Key Templates
+Key templates are used by routines that interface to
+.I factotum
+such as
+.B auth_proxy
+and
+.B auth_challenge
+(see
+.IR auth (2))
+to specify which key and protocol to use for an authentication.
+Like a key tuple, a key template is also a list of 
+.IB attribute = value
+pairs.
+It must specify at least the protocol and enough
+other attributes to uniquely identify a key, or set of keys, to use.
+The keys chosen are those that match all the attributes specified
+in the template.  The possible attribute/value formats are:
+.TP 1i
+.IB attr = val
+The attribute
+.I attr
+must exist in the key and its value must exactly
+match
+.I val
+.TP 1i
+.IB attr ?
+The attribute
+.I attr
+must exist in the key but its value doesn't matter.
+.TP 1i
+.I attr
+The attribute
+.I attr
+must exist in the key with a null value
+.PD
+.PP
+Key templates are also used by factotum to request a key either via
+an RPC error or via the
+.B needkey
+interface.
+The possible attribute/value formats are:
+.TP 1i
+.IB attr = val
+This pair must remain unchanged
+.TP 1i
+.IB attr ?
+This attribute needs a value
+.TP 1i
+.I attr
+The pair must remain unchanged
+.PD
+.SS "Control and Key Management
+.PP
+A number of messages can be written to the control file.
+The messages are:
+.TP
+.B "key \fIattribute-value-list\fP
+add a new key.  This will replace any old key whose
+public, i.e. non ! attributes, match.
+.TP
+.B "delkey \fIattribute-value-list\fP
+delete a key whose attributes match those given.
+.TP
+.B debug
+toggle debugging on and off, i.e., the debugging also
+turned on by the
+.B \-d
+option.
+.PP
+By default when factotum starts it looks for a
+.IR secstore (1)
+account on $auth for the user and, if one exists,
+prompts for a secstore password in order to fetch
+the file
+.IR factotum ,
+which should contain control file commands.
+An example would be
+.EX
+  key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229
+  key proto=rsa service=ssh size=1024 ek=3B !dk=...
+.EE
+where the first line sets a password for
+challenge/response authentication, strong against dictionary
+attack by being a long random string, and the second line
+sets a public/private keypair for ssh authentication,
+generated by
+.B ssh_genkey
+(see
+.IR ssh (1)).
+.PD
+.SS "Confirming key use
+.PP
+The 
+.B confirm
+file provides a connection from
+.I factotum
+to a confirmation server, normally the program
+.IR auth/fgui .
+Whenever a key with the
+.B confirm
+attribute is used, 
+.I factotum
+requires confirmation of its use.  If no process has
+.B confirm
+opened, use of the key will be denied.
+However, if the file is opened a request can be read from it
+with the following format:
+.PP
+.B confirm
+.BI tag= tagno
+.I "<key template>
+.PP
+The reply, written back to
+.BR confirm ,
+consists of string:
+.PP
+.BI tag= tagno
+.BI answer= xxx
+.PP
+If
+.I xxx
+is the string
+.B yes
+then the use is confirmed and the authentication will proceed.
+Otherwise, it fails.
+.PP
+.B Confirm
+is exclusive open and can only be opened by a process with
+the same user id as
+.IR factotum .
+.SS "Prompting for keys
+.PP
+The 
+.B needkey
+file provides a connection from
+.I factotum
+to a key server, normally the program
+.IR auth/fgui .
+Whenever
+.I factotum
+needs a new key, it first checks to see if
+.B needkey
+is opened.  If it isn't, it returns a error to its client.
+If the file is opened a request can be read from it
+with the following format:
+.PP
+.B needkey
+.BI tag= tagno
+.I "<key template>
+.PP
+It is up to the reader to then query the user for any missing fields,
+write the key tuple into the
+.B ctl
+file, and then reply by writing into the
+.B needkey
+file the string:
+.PP
+.BI tag= tagno
+.PP
+.B Needkey
+is exclusive open and can only be opened by a process with
+the same user id as
+.IR factotum .
+.SS "The RPC Protocol
+Authentication is performed by
+.IP 1)
+opening
+.BR rpc
+.IP 2)
+setting up the protocol and key to be used (see the
+.B start
+RPC below),
+.IP 3)
+shuttling messages back and forth between
+.IR factotum
+and the other party (see the
+.B read
+and
+.B write
+RPC's) until done
+.IP 4)
+if successful, reading back an
+.I AuthInfo
+structure (see
+.IR authsrv (2)).
+.PP
+The RPC protocol is normally embodied by one of the
+routines in
+.IR auth (2).
+We describe it here should anyone want to extend
+the library.
+.PP
+An RPC consists of writing a request message to
+.B rpc
+followed by reading a reply message back.
+RPC's are strictly ordered; requests and replies of
+different RPC's cannot be interleaved.
+Messages consist of a verb, a single space, and data.
+The data format depends on the verb.  The request verbs are:
+.TP
+.B "start \fIattribute-value-list\fP
+start a new authentication.
+.I Attribute-value-pair-list
+must include a
+.B proto
+attribute, a
+.B role
+attribute with value
+.B client
+or
+.BR server ,
+and enough other attributes to uniquely identify a key to use.
+A
+.B start
+RPC is required before any others.    The possible replies are:
+.RS
+.TP
+.B ok
+start succeeded.
+.TP
+.B "error \fIstring\fP
+where
+.I string
+is the reason.
+.RE
+.PD
+.TP
+.B read
+get data from
+.I factotum
+to send to the other party.  The possible replies are:
+.RS
+.TP
+.B ok
+read succeeded, this is zero length message.
+.TP
+.B "ok \fIdata\fP
+read succeeded, the data follows the space and is
+unformatted.
+.TP
+.B "done
+authentication has succeeded, no further RPC's are
+necessary
+.TP
+.B "done haveai
+authentication has succeeded, an
+.B AuthInfo
+structure (see
+.IR auth (2))
+can be retrieved with an
+.B authinfo
+RPC
+.TP
+.B "phase \fIstring\fP
+its not your turn to read, get some data from
+the other party and return it with a write RPC.
+.TP
+.B "error \fIstring\fP
+authentication failed,
+.I string
+is the reason.
+.TP
+.B "protocol not started
+a
+.B start
+RPC needs to precede reads and writes
+.TP
+.B "needkey \fIattribute-value-list\fP
+a key matching the argument is needed.  This argument
+may be passed as an argument to
+.I factotum
+.B -g
+in order to prompt for a key.  After that, the
+authentication may proceed, i.e., the read restarted.
+.PD
+.RE
+.TP
+.B "write \fIdata\fP
+send data from the other party to
+.IR factotum .
+The possible replies are:
+.RS
+.TP
+.B "ok
+the write succeeded
+.TP
+.B "needkey \fIattribute-value-list\fP
+see above
+.TP
+.B "toosmall \fIn\fP
+the write is too short, get more data from the
+other party and retry the write.
+.I n
+specifies the maximun total number of bytes.
+.TP
+.B "phase \fIstring\fP
+its not your turn to write, get some data from
+.I factotum
+first.
+.TP
+.B "done
+see above
+.TP
+.B "done haveai
+see above
+.RE
+.TP
+.B authinfo
+retrieve the AuthInfo structure.  
+The possible replies are:
+.RS
+.TP
+.B "ok \fIdata\fP
+.I data
+is a marshaled form of the AuthInfo structure.
+.TP
+.B "error \fIstring\fP
+where
+.I string
+is the reason for the error.
+.PD
+.RE
+.TP
+.B attr
+retrieve the attributes used in the
+.B start
+RPC.
+The possible replies are:
+.RS
+.TP
+.B "ok \fIattribute-value-list\fP
+.TP
+.B "error \fIstring\fP
+where
+.I string
+is the reason for the error.
+.PD
+.RE
+.SH SOURCE
+.B /sys/src/cmd/auth/factotum
diff --git a/sys/man/4/flashfs b/sys/man/4/flashfs
new file mode 100755
index 000000000..ee8f5dc21
--- /dev/null
+++ b/sys/man/4/flashfs
@@ -0,0 +1,74 @@
+.TH FLASHFS 4
+.SH NAME
+flashfs \- journalling file system for flash memory
+.SH SYNOPSIS
+.B aux/flashfs
+[
+.B -Dr
+] [
+.B -n
+.I nsect
+] [
+.B -z
+.I sectsize
+]
+[
+.B -f
+.I file
+]
+[
+.B -m
+.I mountpoint
+]
+.SH DESCRIPTION
+.I Flashfs
+interprets the journal-based file system created by
+.IR mkflashfs (8)
+and stored in
+.I file
+(default
+.BR /dev/flash/fs )
+so that it can be mounted into a Plan 9 file system.
+.I Flashfs
+is typically used to create a stand alone file system from
+a small persistent storage device, such as an erasable flash memory.
+It does not authenticate its clients and assumes each group
+has a single member with the same name.
+.PP
+The
+.B -s
+option causes
+.I flashfs
+to post its channel on
+.BR #s/flashfs .
+.I Flashfs
+mounts itself on
+.IR mountpoint
+(default
+.BR /n/brzr ).
+The
+.B -D
+option turns on 9P debugging output.
+The
+.B -r
+option makes the file system read-only.
+.PP
+The files and directory structure are divided into
+.I sectsize
+(default
+.BR 4096 )
+byte blocks.
+Larger blocks make large files more compact but take longer to access.
+Supplying the
+.B -n
+option forces
+.I file
+to contain exactly
+.I nsect
+sectors.
+.SH SOURCE
+.B /sys/src/cmd/aux/flashfs
+.SH "SEE ALSO"
+.IR paqfs (4),
+.IR sacfs (4),
+.IR mkflashfs (8)
diff --git a/sys/man/4/fossil b/sys/man/4/fossil
new file mode 100755
index 000000000..602410a14
--- /dev/null
+++ b/sys/man/4/fossil
@@ -0,0 +1,506 @@
+.TH FOSSIL 4
+.SH NAME
+fossil, flchk, flfmt \- archival file server
+.SH SYNOPSIS
+.B fossil/fossil
+[
+.B -Dt
+]
+[
+.B -c
+.I cmd
+]...
+[
+.B -f
+.I file
+]
+[
+.B -m
+.I free-memory%
+]
+.PP
+.B fossil/flchk
+[
+.B -f
+]
+[
+.B -c
+.I ncache
+]
+[
+.B -h
+.I host
+]
+.I file
+.PP
+.B fossil/flfmt
+[
+.B -y
+]
+[
+.B -b
+.I blocksize
+]
+[
+.B -h
+.I host
+]
+[
+.B -l
+.I label
+]
+[
+.B -v
+.I score
+]
+.I file
+.PP
+.B fossil/conf
+[
+.B -w
+]
+.I file
+[
+.I config
+]
+.PP
+.B fossil/last
+.I file
+.SH DESCRIPTION
+.I Fossil
+is the main file system for Plan 9.
+Unlike the Plan 9 file servers of old,
+.I fossil
+is a collection of user-space programs that run on a standard Plan 9 kernel.
+The name of the main fossil file server at Murray Hill is
+.BR pie .
+The Plan 9 distribution file server,
+.BR sources ,
+is also a fossil server.
+.PP
+.I Fossil
+is structured as a magnetic disk write buffer
+optionally backed by a Venti server for archival storage.
+It serves the Plan 9 protocol via TCP.
+A
+.I fossil
+file server conventionally presents
+three trees in the root directory of each file system:
+.BR active ,
+.BR archive ,
+and
+.BR snapshot .
+.B /active
+is the root of a conventional file system
+whose blocks are stored in a disk file.
+In a typical configuration, the file server periodically
+marks the entire file system copy-on-write, effectively
+taking a snapshot of the file system at that moment.
+This snapshot is made available in a name
+created from the date and time of the snapshot:
+.BI /snapshot/ yyyy / mmdd / hhmm \fR,
+where
+.I yyyy
+is the full year,
+.I mm
+is the month number,
+.I dd
+is the day number,
+.I hh
+is the hour,
+and
+.I mm
+is the minute.
+The snapshots in
+.B /snapshot
+are ephemeral: eventually they are deleted
+to reclaim the disk space they occupy.
+Long-lasting snapshots stored on a Venti server
+are kept in 
+.B /archive
+and also named from the date (though not the time) of the snapshot:
+.BI /archive/ yyyy / mmdds \fR,
+where
+.IR yyyy ,
+.IR mm ,
+and
+.I dd
+are year, month, and day as before,
+and
+.I s
+is a sequence number if more than one
+archival snapshot is done in a day.
+For the first snapshot,
+.I s
+is null.
+For the subsequent snapshots,
+.I s
+is
+.BR .1 ,
+.BR .2 ,
+.BR .3 ,
+etc.
+The root of the main file system that is frozen
+for the first archival snapshot of December 15, 2002
+will be named
+.BR /archive/2002/1215/ .
+.PP
+The attach name used in
+.I mount
+(see
+.IR bind (1),
+.IR bind (2)
+and
+.IR attach (5))
+selects a file system to be served
+and optionally a subtree,
+in the format
+.IB fs \fR[\fB/ dir \fR].
+An empty attach name selects
+.BR main/active .
+.PP
+.I Fossil
+normally requires all users except
+.L none
+to provide authentication tickets on each
+.IR attach (5).
+To keep just anyone from connecting,
+.L none
+is only allowed to attach after another user
+has successfully attached on the same
+connection.
+The other user effectively acts as a chaperone
+for
+.LR none .
+Authentication can be disabled using the
+.B -A
+flag to
+.B open
+or
+.B srv
+(see
+.IR fossilcons (8)).
+.PP
+The groups called
+.B noworld
+and
+.B write
+are special on the file server.
+Any user belonging to
+.B noworld
+has attenuated access privileges.
+Specifically, when checking such a user's access to files,
+the file's permission bits are first ANDed
+with 0770 for normal files and 0771 for directories.
+The effect is to deny world access permissions to
+.B noworld
+users, except when walking into directories.
+If the
+.B write
+group exists, then the file system appears read-only
+to users not in the group.
+This is used to make the Plan 9 distribution file server
+.RI ( sources.cs.bell-labs.com )
+readable by the world but writable only to the developers.
+.PP
+.I Fossil
+starts a new instance of the fossil file server.
+It is configured mainly through console commands,
+documented in
+.IR fossilcons (8).
+.PP
+The options are:
+.TP
+.B -D
+Toggle the debugging flag, which is initially off.
+When the flag is set, information about authentication
+and all protocol messages are written to standard error.
+.TP
+.B -t
+Start a file server console on
+.BR /dev/cons .
+If this option is given,
+.I fossil
+does not fork itself into the background.
+.TP
+.BI -c " cmd
+Execute the console command
+.IR cmd .
+This option may be repeated to give multiple
+commands.
+Typically the only commands given on the
+command line are
+.RB `` . \fIfile \fR,''
+which executes a file containing commands,
+and
+.RB `` "srv -p" \fIcons \fR,''
+which starts a file server console on
+.BI /srv/ cons \fR.
+See
+.IR fossilcons (8)
+for more information.
+.TP
+.BI -f " file
+Read and execute console commands stored in the Fossil disk 
+.IR file .
+.I Conf
+.RI ( q.v. )
+reads and writes the command set stored in the disk.
+.TP
+.B -m
+Allocate
+.I free-memory%
+percent of the available free RAM for buffers.
+This overrides all other memory sizing parameters,
+notably the
+.B -c
+option to
+.BR open .
+.PD
+.PP
+.I Flchk
+checks the fossil file system stored in
+.I file
+for inconsistencies.
+.I Flchk
+is deprecated in favor of the console
+.B check
+command (see
+.IR fossilcons (8)).
+.I Flchk
+prints
+.I fossil
+console commands that may be
+executed to take care of
+bad pointers
+.RB ( clrp ),
+bad entries
+.RB ( clre ),
+bad directory entries
+.RB ( clri ),
+unreachable blocks
+.RB ( bfree ).
+Console commands are interspersed with
+more detailed commentary on the file system.
+The commands are distinguished by being prefixed with
+sharp signs.
+Note that all proposed fixes are rather drastic: offending
+pieces of file system are simply chopped off.
+.PP
+.I Flchk
+does
+.I not
+modify the file system, so it is safe to
+run concurrently with
+.IR fossil ,
+though in this case
+the list of unreachable
+blocks and any inconsistencies involving the active file system
+should be taken with a grain of salt.
+.PP
+The options are:
+.TP
+.B -f
+Fast mode.
+By default,
+.I flchk
+checks the entire file system image for consistency,
+which includes all the archives to Venti
+and can take a very long time.
+In fast mode,
+.I flchk
+avoids walking in Venti blocks
+whenever possible.
+.TP
+.BI -c " ncache
+Keep a cache of
+.I ncache
+(by default, 1000)
+file system blocks in memory during the check.
+.TP
+.BI -h " host
+Use
+.I host
+as the Venti server.
+.PD
+.PP
+.I Flfmt
+prepares
+.I file
+as a new fossil file system.
+The file system is initialized with three empty directories
+.BR active ,
+.BR archive ,
+and
+.BR snapshot ,
+as described above.
+The options are:
+.TP
+.B -y
+Yes mode.
+By default,
+.I flfmt
+will prompt for confirmation before formatting
+a file that already contains a fossil file system,
+and before formatting a file that is not served
+directly by a kernel device.
+If the
+.B -y
+flag is given, no such checks are made.
+.TP
+.BI -b " blocksize
+Set the file system block size (by default, 8192).
+.TP
+.BI -h " host
+Use
+.I host
+as the Venti server.
+.TP
+.BI -l " label
+Set the textual label on the file system to
+.IR label .
+The label is only a comment.
+.TP
+.BI -v " score
+Initialize the file system using the vac file
+system stored on Venti at
+.IR score .
+The score should have been generated by
+.I fossil
+rather than by
+.IR vac (1),
+so that the appropriate snapshot metadata is present.
+.PD
+.PP
+.I Conf
+reads or writes the configuration branded on the Fossil disk
+.IR file .
+By default, it reads the configuration from the disk and prints it to
+standard output.
+If the
+.B -w
+flag is given,
+.I conf
+reads a new configuration from 
+.I config
+(or else from standard input)
+and writes it to the disk.
+Inside the configuration file, the argument
+.L *
+may be used to stand in for the name of the disk holding the configuration.
+The Plan 9 kernel boot process runs
+.RB `` fossil
+.B -f
+.IR disk ''
+to start a Fossil file server.
+The disk is just a convenient place to store configuration
+information.
+.PP
+.I Last
+prints the vac score that resulted after the most recent archival snapshot 
+of the fossil in
+.I file.
+.SH EXAMPLES
+.PP
+Place the root of the archive file system on
+.B /n/dump
+and show the modified times of the MIPS C compiler
+over all dumps in December 2002:
+.IP
+.EX
+9fs dump
+ls -l /n/dump/2002/12*/mips/bin/vc
+.EE
+.PP
+To get only one line of output for each version of the compiler:
+.IP
+.EX
+ls -lp /n/dump/2002/12*/mips/bin/vc | uniq
+.EE
+.ne 14
+.PP
+Initialize a new file system, start the server with permission
+checking turned off, create a users file, and mount the server:
+.IP
+.EX
+fossil/flfmt /dev/sdC0/fossil
+fossil/conf -w /dev/sdC0/fossil <<EOF
+fsys main config /dev/sdC0/fossil
+fsys main open -AWP
+fsys main
+create /active/adm adm sys d775
+create /active/adm/users adm sys 664
+users -w
+srv -p fscons
+srv fossil
+EOF
+fossil/fossil -f /dev/sdC0/fossil
+mount /srv/fossil /n/fossil
+.EE
+.LP
+See the discussion of the
+.B users
+and
+.B uname
+commands in
+.IR fossilcons (8)
+for more about the user table.
+.ne 3
+.PP
+Perhaps because the disk has been corrupted or replaced,
+format a new file system using the last archive score printed
+on the console:
+.IP
+.EX
+fossil/flfmt -v b9b3...5559 /dev/sdC0/fossil
+.EE
+.LP
+Note that while
+.B /snapshot
+will be lost,
+.B /active
+and
+.B /archive
+will be restored to their contents at the time of the
+last archival snapshot.
+.ne 3
+.PP
+Blindly accept the changes prescribed by
+.I flchk
+(not recommended):
+.IP
+.EX
+fossil/flchk /dev/sdC0/fossil | sed -n 's/^# //p' >>/srv/fscons
+.EE
+.LP
+A better strategy is to vet the output,
+filter out any suggestions you're not comfortable with,
+and then use the
+.I sed
+command to prepare the script.
+.SH SOURCE
+.B /sys/src/cmd/fossil
+.SH SEE ALSO
+.IR yesterday (1),
+.IR fs (3),
+.IR fs (4),
+.IR srv (4),
+.IR fossilcons (8),
+.IR venti (8)
+.SH BUGS
+It is possible that the disk format (but not the Venti format)
+will change in the future, to make the disk a full cache
+rather than just a write buffer.
+Changing to the new format will require reformatting
+the disk as in the example above,
+but note that this will preserve most of the file system
+(all but
+.BR /snapshot )
+with little effort.
+.PP
+The
+.B -m
+option currently assumes a block size of 8K bytes,
+and a single file system per
+.I fossil
+instance.
diff --git a/sys/man/4/fs b/sys/man/4/fs
new file mode 100755
index 000000000..808dd9720
--- /dev/null
+++ b/sys/man/4/fs
@@ -0,0 +1,150 @@
+.TH FS 4
+.SH NAME
+fs \- file server, dump
+.SH SYNOPSIS
+.I none
+.SH DESCRIPTION
+The file server was the main file system for Plan 9.
+It was a stand-alone system that ran on
+a separate computer.
+It served the Plan 9 protocol via the IL/IP
+protocols on Ethernets.
+The name of the main file server at Murray Hill was
+.BR emelie .
+.PP
+The file server normally requires all users except
+.L none
+to provide authentication tickets on each
+.IR attach (5).
+This can be disabled using the
+.B noauth
+configuration command (see
+.IR fsconfig (8)).
+.PP
+The group numbered 9999, normally called
+.BR noworld ,
+is special
+on the file server.  Any user belonging to that group has
+attenuated access privileges.  Specifically, when checking such
+a user's access to files, the file's permission bits are first ANDed
+with 0770 for normal files or 0771 for directories.  The effect is
+to deny world access permissions to
+.B noworld
+users, except
+when walking directories.
+.PP
+The user
+.B none
+is always allowed to attach to
+.B emelie
+without authentication but has minimal permissions.
+.PP
+.B Emelie
+maintains three file systems
+on a combination of disks and
+write-once-read-many (WORM) magneto-optical disks.
+.TP
+.B other
+is a simple disk-based file system similar to
+.IR kfs (4) .
+.TP
+.B main
+is a worm-based file system with a disk-based
+look-aside cache.
+The disk cache holds
+modified worm blocks
+to overcome the write-once property of the worm.
+The cache also holds recently accessed
+non-modified blocks to
+speed up the effective access time of the worm.
+Occasionally
+(usually daily at 5AM) the modified blocks in the
+disk cache are
+.IR dumped .
+At this time,
+traffic to the file system is halted and the
+modified blocks are relabeled to the unwritten
+portion of the worm.
+After the dump,
+the file system traffic is continued and
+the relabeled blocks are copied to the worm by
+a background process.
+.TP
+.B dump
+Each time the main file system is dumped,
+its root is appended to a subdirectory of the dump file system.
+Since the dump file system is not mirrored with a disk
+cache,
+it is read-only.
+The name of the newly added root is created from the date
+of the dump:
+.BI / yyyy / mmdds\f1.
+Here
+.I yyyy
+is the full year,
+.I mm
+is the month number,
+.I dd
+is the day number and
+.I s
+is a sequence number if more than
+one dump is done in a day.
+For the first dump,
+.I s
+is null.
+For the subsequent dumps
+.I s
+is 1, 2, 3, etc.
+.sp
+The root of the main file system
+that is frozen on the first dump
+of March 1, 1992
+will be named
+.B /1992/0301/
+in the dump file system.
+.SH EXAMPLES
+Place the root of the
+.B dump
+file system on
+.B /n/dump
+and show the modified times of the MIPS C compiler
+over all dumps in February, 1992:
+.IP
+.EX
+9fs dump
+ls -l /n/dump/1992/02??/mips/bin/vc
+.EE
+.PP
+To get only one line of output for each version of the compiler:
+.IP
+.EX
+ls -lp /n/dump/1992/02??/mips/bin/vc | uniq
+.EE
+.PP
+Make the
+.B other
+file system available in directory
+.BR /n/emelieother :
+.IP
+.EX
+mount -c /srv/boot /n/emelieother other
+.EE
+.SH SOURCE
+.B /sys/src/fs
+.SH SEE ALSO
+.IR yesterday (1),
+.IR cwfs (4),
+.IR srv (4),
+.IR fs (8)
+.br
+Sean Quinlan,
+``A Cached WORM File System'',
+.I
+Software \- Practice and Experience,
+December, 1991
+.SH BUGS
+For the moment, the file server serves both the old (third edition) and new (fourth
+edition) versions of 9P, deciding which to serve by sniffing the first packet on each
+connection.
+.PP
+Required IL, thus now deprecated.
diff --git a/sys/man/4/ftpfs b/sys/man/4/ftpfs
new file mode 100755
index 000000000..0a827b0ee
--- /dev/null
+++ b/sys/man/4/ftpfs
@@ -0,0 +1,218 @@
+.TH FTPFS 4
+.SH NAME
+ftpfs  \- file transfer protocol (FTP) file system
+.SH SYNOPSIS
+.B ftpfs
+[
+.B -/dqnt
+]
+[
+.B -m
+.I mountpoint
+]
+[
+.B -a
+.I password
+]
+[
+.B -e
+.I ext
+]
+[
+.B -k
+.I keyspec
+]
+[
+.B -o
+.I os
+]
+[
+.B -r
+remoteroot
+]
+.I system
+.SH DESCRIPTION
+.I Ftpfs
+dials the TCP file transfer protocol (FTP) port, 21, on
+.I system
+and mounts itself (see
+.IR bind (2))
+on
+.I mountpoint
+(default
+.BR /n/ftp )
+to provide access via FTP to files on the remote machine.
+.I Ftpfs
+attempts to use FTP's `passive' mode
+but falls back to using `active' mode if that fails.
+If required by the remote machine,
+.I ftpfs
+will ask
+.IR factotum (4)
+for a key matching the pattern
+.IP
+.EX
+proto=pass service=ftp server=\fIsystem\fP user? !password? \fIkeyspec\fP
+.EE
+.PP
+(If
+.I factotum
+does not have such a key,
+.I factotum
+will prompt the user for one.)
+.PP
+The user names
+.B ftp
+and
+.B anonymous
+conventionally offer guest/read-only access to
+machines.
+Anonymous FTP may be called without using factotum
+by using the
+.B -a
+option and specifying the
+.IR password .
+.PP
+By default the file seen at the mount point is the user's
+remote home directory if he has one.
+The option
+.B -/
+forces the mount point to correspond to the
+remote root.
+The option
+.B -r
+forces the mount point to correspond to the
+remote directory
+.IR remoteroot .
+.PP
+To avoid seeing startup messages from the server use option
+.BR -q .
+To see all messages from the server use option
+.BR -d .
+.PP
+Some systems will hangup an ftp connection that has no activity
+for a given period.  The
+.BR -K
+option causes ftp to send a NOP command every 15 seconds to attempt
+to keep the connection open.  This command can cause some servers to
+hangup, so you'll have to feel your way.
+.PP
+The
+.B -t
+option causes
+.I ftpfs
+to negotiate TLS encryption with the server.
+.PP
+To terminate the connection,
+.B unmount
+(see
+.IR bind (1))
+the mount point.
+.PP
+Since there is no specified format for metadata retrieved
+in response to an FTP directory request,
+.I ftpfs
+has to apply heuristics to steer the interpretation.  Sometimes,
+though rarely, these heuristics fail.  The following options are
+meant as last resorts to try to steer interpretation.
+.PP
+A major clue to the heuristics is the operating system at the other
+end.  Normally this can be determined automatically using the
+FTP SYST command.  However, in some cases the server doesn't implement
+the SYST command.  The
+.B -o
+option will force the case by specifying the name of the operating
+system.  Known system types are:
+.BR UNIX ,
+.BR SUN ,
+.BR TOPS ,
+.BR Plan9 ,
+.BR VM ,
+.BR VMS ,
+.BR MVS ,
+.BR NetWare ,
+.BR OS/2 ,
+.BR TSO ,
+and
+.BR WINDOWS_NT .
+.PP
+Some systems and/or FTP servers return directory listings that don't
+include the file extension.  The
+.B -e
+option allows the user to specify an extension to append to all
+remote files (other than directories).
+.PP
+Finally, there are two FTP commands to retrieve the contents of a
+directory, LIST and NLST.  LIST is approximately equivalent to
+.L ls -l
+and NLST to
+.LR ls .
+.I Ftpfs
+normally uses LIST.  However, some FTP servers interpret LIST
+to mean, give a wordy description of the file.
+.I Ftpfs
+normally notices this and switches to using NLST.  However, in
+some rare cases, the user must force the use of NLST with the
+.B -n
+option.
+.SH EXAMPLE
+You want anonymous FTP access to the system
+.BR export.lcs.mit.edu .
+The first
+.IR import (4)
+command is only necessary if your machine does not have access to the
+desired system, but another, called
+.B gateway
+in this example, does.
+.IP
+.EX
+import gateway /net
+ftpfs -a yourname@yourmachine export.lcs.mit.edu
+.EE
+.SH SOURCE
+.B /sys/src/cmd/ip/ftpfs
+.SH "SEE ALSO"
+.IR bind (2)
+.SH BUGS
+Symbolic links on remote Unix systems will always have mode 0777
+and a length of 8.
+.PP
+After connecting to a TOPS-20 system, the mount point will contain
+only one directory, usually
+.BR /n/ftp/PS:<ANONYMOUS> .
+However, walking to any valid directory on that machine will succeed
+and cause that directory entry to appear under the mount point.
+.PP
+.I Ftpfs
+caches files and directories.  A directory will fall from the cache
+after 5 quiescent minutes or if the local user changes the
+directory by writing or removing a file.
+Otherwise, remote
+changes to the directory that occur after the directory has
+been cached might not be immediately visible.
+Attempting to walk to
+.IB directory /.flush.ftpfs
+will flush
+.I directory
+from the cache, thus forcing
+.I ftpfs
+to re-read it.
+.PP
+There is no way to issue the appropriate commands to handle special synthetic
+FTP file types such as directories
+that automatically return a
+.B tar
+of their contents.
+.PP
+.I Ftpfs
+makes copies in
+.B /tmp
+of files being transferred,
+so its effects might not be immediate.
+If there is enough main memory, you might want to run
+.IR ramfs (4)
+first.
+.PP
+Filenames containing spaces will confuse
+.I ftpfs
+(and other FTP clients).
diff --git a/sys/man/4/httpfile b/sys/man/4/httpfile
new file mode 100755
index 000000000..8d3b428df
--- /dev/null
+++ b/sys/man/4/httpfile
@@ -0,0 +1,86 @@
+.TH HTTPFILE 4
+.SH NAME
+httpfile \- serve a single web file
+.SH SYNOPSIS
+.B httpfile
+[
+.B -9d
+]
+[
+.B -c
+.I count
+]
+[
+.B -f
+.I file
+]
+[
+.B -m
+.I mtpt
+]
+[
+.B -s
+.I srvname
+]
+[
+.B -x
+.I net
+]
+.I url
+.SH DESCRIPTION
+.I Httpfile
+serves the web page specified by the URL
+.I url
+as a new file
+.I file
+in the directory
+.IR mtpt .
+The default
+.I file
+is the last path element of the URL,
+and the default
+.I mtpt
+is the current directory.
+.PP
+.I Httpfile
+does not download large files all at once.
+Instead, it requests 64-kilobyte blocks as they are
+needed to satisfy reads, caching a few blocks in memory at a time.
+.PP
+The 
+.B -D
+and
+.B -d
+options enable a trace of the 9P traffic
+and general debugging messages.
+.PP
+The
+.B -s
+option causes 
+.I httpfile
+to post the 9P service as
+.BI /srv/ srvname
+and disables the default mount.
+.PP
+The
+.B -x
+option specifies an alternate network directory
+.RI ( e.g., 
+.BR /net.alt ).
+.PP
+The
+.B -c
+option sets the number of file blocks kept cached in memory (default 32).
+.SH EXAMPLE
+Mount an ISO image on a web server:
+.IP
+.EX
+ip/httpfile http://www.9grid.de/plan9/plan9.iso
+9660srv
+mount /srv/9660 /n/iso plan9.iso
+.EE
+.SH SOURCE
+.B /sys/src/cmd/ip/httpfile.c
+.SH "SEE ALSO
+.IR hget (1),
+.IR webfs (4)
diff --git a/sys/man/4/import b/sys/man/4/import
new file mode 100755
index 000000000..d8026c7af
--- /dev/null
+++ b/sys/man/4/import
@@ -0,0 +1,202 @@
+.TH IMPORT 4
+.SH NAME
+import \- import a name space from a remote system
+.SH SYNOPSIS
+.B import
+[
+.I options
+]
+.I system
+.I file
+[
+.I mountpoint
+]
+.PP
+.B import
+.B -B
+[
+.I options
+]
+.I mountpoint
+[
+.I cmd
+[
+.I args ...
+]
+]
+.SH DESCRIPTION
+.I Import
+allows an arbitrary
+.I file
+on a remote
+.I system
+to be imported into the local name space.
+Usually
+.I file
+is a directory, so the complete
+file tree under the directory is made available.
+.PP
+A process is started on the
+remote machine, with authority of the user of
+.IR import ,
+to perform work for the local machine using the
+.IR exportfs (4)
+service.
+The default port used is TCP 17007.
+If
+.I mountpoint
+is omitted
+.I import
+uses the name of the remote
+.I file
+as the local mount point.
+.PP
+The options are:
+.TF "-s namexxx"
+.PD
+.TP
+.B -a -b -c -C
+Control the construction of union directories, as in
+.I mount
+and
+.IR bind (1).
+Only valid when 
+.I file
+is a directory.
+.TP
+.B -A
+Skip the authentication protocol.
+This is useful for connecting to foreign systems like Inferno.
+.TP
+.B -B
+Run in ``backwards'' mode, described below.
+.TP
+.B -E \fIenc
+Push an authentication protocol on its network connection.
+The supported protocols are
+.B clear
+(the default, no protocol)
+and
+.BR ssl .
+There are plans to make
+.B tls
+available.
+.TP
+.B -e '\fIenc auth\fR'
+Specify the encryption and authentication algorithms to use for
+encrypting the wire traffic
+(see
+.IR ssl (3)).
+The defaults are
+.B rc4_256
+and
+.BR sha1 .
+.TP
+.B -k \fIkeypattern
+Use
+.I keypattern
+to select a key to authenticate to the remote side
+(see
+.IR auth (2)).
+.TP
+.B -o -O
+These equivalent flags run
+.I import
+in a pre-9P2000 compatibility mode to import from ancient servers.
+.TP
+.B -p
+Push the
+.IR aan (8)
+filter onto the connection to protect against
+temporary network outages.
+.TP
+.B -s \fIname
+Post the connection's mountable file descriptor as
+.BI /srv/ name\fR.
+.PD
+.PP
+The 
+.B -B
+option runs
+.I import
+in ``backwards'' mode.
+In this mode,
+.I import
+runs a
+.I p9any
+authentication (as server) over its file descriptor 0
+(expected to be an incoming network connection from
+.B exportfs
+.BR -B ),
+mounts the connection onto
+.IR mntpt ,
+and optionally runs
+.I cmd
+.IR args .
+.SH EXAMPLES
+Assume a machine
+.B kremvax
+that has IP interfaces for the company intranet and the global
+internet mounted on
+.I /net
+and
+.I /net.alt
+respectively.
+Any machine inside the company can get telnet out to the global
+internet using:
+.IP
+.EX
+import -a kremvax /net.alt
+telnet /net.alt/tcp!ucbvax
+.EE
+.PP
+Suppose that the machine
+.B moscvax
+has access to a private file server containing public web pages
+that need to be served by the less-trusted server
+.BR webvax .
+.B Webvax
+runs the following listener 
+(see
+.IR listen (8))
+on TCP port 999:
+.IP
+.EX
+#!/bin/rc
+import -B -s rowebfs /usr/web /bin/restarthttpd
+.EE
+.PP
+When
+.B moscvax
+boots, it runs
+.IP
+.EX
+exportfs -R -r /usr/web -B tcp!webvax!999
+.EE
+.PP
+to serve a read-only copy of
+.B /usr/web
+to
+.BR webvax .
+When
+.B webvax
+gets the call, 
+.B import
+mounts the served tree onto its own
+.B /usr/web
+and then runs
+.B /bin/restarthttpd
+to restart
+.IR httpd (8).
+.SH SOURCE
+.B /sys/src/cmd/import.c
+.SH SEE ALSO
+.IR bind (1),
+.IR ssl (3),
+.IR exportfs (4),
+.IR srv (4),
+.IR aan (8),
+.IR listen (8),
+.B cs
+in
+.IR ndb (8)
diff --git a/sys/man/4/iostats b/sys/man/4/iostats
new file mode 100755
index 000000000..9472f20b5
--- /dev/null
+++ b/sys/man/4/iostats
@@ -0,0 +1,82 @@
+.TH IOSTATS 4
+.SH NAME
+iostats \- file system to measure I/O
+.SH SYNOPSIS
+.B iostats
+[
+.B -d
+]
+[
+.B -f
+.I dbfile
+]
+.I cmd
+[
+.I args...
+]
+.SH DESCRIPTION
+.I Iostats
+is a user-level file server that interposes itself between a program
+and the regular file server, which
+allows it to gather statistics of file system
+use at the level of the Plan 9 file system protocol, 9P.
+After a program
+exits a report is printed on standard error.
+.PP
+The report consists of three sections.
+The first section reports the amount
+of user data in
+.B read
+and
+.B write
+messages sent by the program and the average rate at
+which the data was transferred.
+The
+.B protocol
+line reports the amount
+of data sent as message headers, that is,
+protocol overhead.
+The
+.B rpc
+line reports the
+total number of file system transactions.
+.PP
+The second section gives
+the number of messages, the fastest, slowest, and average turn around
+time and the amount of data involved with each 9P
+message type.
+The final section gives an I/O summary for each file used
+by the program in terms of opens, reads and writes.
+.PP
+If the
+.B -d
+flag is present, a debugging log including all traffic
+is written to
+.I dbfile
+(default
+.BR iostats.out ).
+.SH EXAMPLE
+Display summary of file I/O incurred by
+.IR ls (1):
+.IP
+.EX
+iostats ls
+.EE
+.PP
+Start a new shell, displaying all 9P traffic caused by the shell or its children:
+.IP
+.EX
+iostats -df /fd/1 rc
+.EE
+.SH SOURCE
+.B /sys/src/cmd/iostats
+.SH SEE ALSO
+.IR dup (3)
+.SH BUGS
+Poor clock resolution means that large amounts of I/O must be done to
+get accurate rate figures.
+.PP
+Can be fooled by programs that do fresh mounts outside its purview,
+or by the use of names of files with content that can vary by process (e.g.,
+.LR #d ,
+.LR /dev/cons ).
diff --git a/sys/man/4/keyfs b/sys/man/4/keyfs
new file mode 100755
index 000000000..c78e31df4
--- /dev/null
+++ b/sys/man/4/keyfs
@@ -0,0 +1,249 @@
+.TH KEYFS 4
+.SH NAME
+keyfs, warning \- authentication database files
+.SH SYNOPSIS
+.B auth/keyfs
+[
+.B -p
+]
+[
+.B -w
+.RB [ np ]
+]
+[
+.BI -m mntpt
+]
+[
+.I keyfile
+]
+.PP
+.B auth/warning
+[
+.B -n
+]
+[
+.B -p
+]
+.SH DESCRIPTION
+.I Keyfs
+serves a two-level file tree for manipulating authentication information.
+It runs on the machine providing authentication service for the local
+Plan 9 network, which may be a dedicated authentication server or
+a CPU server.
+The programs described in
+.IR auth (8)
+use
+.I keyfs
+as their interface to the authentication database.
+.PP
+.I Keyfs
+reads and decrypts file
+.I keyfile
+(default
+.BR /adm/keys )
+using the DES key,
+which is by default read from
+.B #r/nvram
+(see
+.IR rtc (3)).
+With option
+.BR -p ,
+.I keyfs
+prompts for a password from which the key is derived.
+.I Keyfile
+holds a 41-byte record for each user in the database.
+Each record is encrypted separately
+and contains the user's name,
+DES key,
+status,
+host status,
+and expiration date.
+The name is a
+null-terminated
+.SM UTF
+string
+.B NAMELEN
+bytes long.
+The status is a byte containing
+binary 0 if the account is enabled,
+1 if it is disabled.
+Host status is a byte containing
+binary 1 if the user is a host,
+0 otherwise.
+The expiration date is four-byte little-endian integer
+which represents the time in seconds since the epoch
+(see
+.IR date (1))
+at which the account will expire.
+If any changes are made to the database that affect the information stored in
+.IR keyfile ,
+a new version of the file is written.
+.PP
+There are two authentication databases,
+one for Plan 9 user information,
+and one for SecureNet user information.
+A user need not be installed in both databases
+but must be installed in the Plan 9 database to connect to a Plan 9 server.
+.PP
+.I Keyfs
+serves an interpretation of the
+.I keyfile
+in the file tree rooted at
+.I mntpt
+(default
+.BR /mnt/keys ).
+Each user
+.I user
+in
+.I keyfile
+is represented as the directory
+.IR mntpt / user .
+.PP
+Making a new directory in
+.I mntpt
+creates a new user entry in the database.
+Removing a directory removes the user entry,
+and renaming it changes the name in the entry.
+Such changes are reflected immediately in
+.IR keyfile .
+.I Keyfs
+does not allow duplicate names when creating or renaming user entries.
+.PP
+All files in the user directories except for
+.B key
+contain
+.SM UTF
+strings with a trailing newline when read,
+and should be written as
+.SM UTF
+strings with or without a trailing newline.
+.B Key
+contains the
+.BR DESKEYLEN -byte
+encryption key for the user.
+.PP
+The following files appear in the user directories.
+.TF expire
+.TP
+.B key
+The authentication key for the user.
+If the user's account is disabled or expired,
+reading this file returns an error.
+Writing
+.I key
+changes the key in the database.
+.TP
+.B log
+The number of consecutive failed authentication attempts for the user.
+Writing the string
+.B bad
+increments this number; writing
+.B good
+resets it to 0.
+This number is not stored in
+.IR keyfile ,
+and is initialized to 0 when
+.I keyfs
+starts.
+When the number reaches a multiple of ten,
+.I keyfs
+temporarily disables the account for that many seconds.
+Reads from the
+.B key
+or
+.B secret
+files during this time return the error
+``user in purgatory.''
+.TP
+.B status
+The current status of the account, either
+.B ok
+or
+.BR disabled .
+Writing
+.B ok
+enables the account;
+writing
+.B disabled
+disables it.
+.TP
+.B expire
+The expiration time for the account.
+When read, it contains either the string
+.B never
+or the time in seconds since the epoch
+that the account will expire.
+When written with strings of the same form,
+it sets the expiration date for the user.
+If the expiration date is reached,
+the account is not disabled,
+but
+.I key
+cannot be read without an error.
+.PD
+.PP
+If the
+.B -w
+option is on,
+.I keyfs
+runs the command
+.I warning
+once every 24 hours to mail people about expiring keys.
+Warnings are sent 14 days and 7 days prior to expiration.
+The argument to
+.BR -w ,
+either
+.B p
+or
+.BR n ,
+is passed to
+.I warning
+to restrict the warnings to
+the Plan 9 or SecureNet database.
+The default for
+.I keyfs
+is not to call
+.I warning
+at all;
+.I warning's
+own default is to warn about both.
+The files
+.B /adm/netkeys.who
+and
+.B /adm/keys.who
+are used to find the mail addresses to send to.
+The first word on each line identifies
+a user.
+Any subsequent strings on the line delimited '<' and '>' are considered mail
+addresses to send warnings to.
+If multiple lines match a user, the last in the file is used.
+.B Changeuser
+(see
+.IR auth (8))
+adds lines to these files.
+.SH FILES
+.TF /adm/netkeys.who
+.TP
+.B /adm/keys
+Encrypted key file for the Plan 9 database.
+.TP
+.B /adm/netkeys
+Encrypted key file for the SecureNet database.
+.TP
+.B /adm/keys.who
+List of users in the Plan 9 database.
+.TP
+.B /adm/netkeys.who
+List of users in  the SecureNet database.
+.TP
+.B #r/nvram
+The non-volatile RAM on the server, which holds the key used
+to decrypt key files.
+.SH SOURCE
+.B /sys/src/cmd/auth/keyfs.c
+.br
+.B /sys/src/cmd/auth/warning.c
+.SH "SEE ALSO"
+.IR authsrv (6),
+.IR namespace (6),
+.IR auth (8)
diff --git a/sys/man/4/kfs b/sys/man/4/kfs
new file mode 100755
index 000000000..15a9514d1
--- /dev/null
+++ b/sys/man/4/kfs
@@ -0,0 +1,136 @@
+.TH KFS 4
+.SH NAME
+kfs \- disk file system
+.SH SYNOPSIS
+.B disk/kfs
+[
+.B -rc
+] [
+.B -b
+.I n
+] [
+.B -f
+.I file
+] [
+.B -n
+.I name
+] [
+.B -p
+.I perm
+] [
+.B -s
+] [
+.B -B
+.I nbuf
+]
+.SH DESCRIPTION
+.I Kfs
+is an old, local user-level file server for a Plan 9 terminal with a disk.
+It maintains a hierarchical Plan 9 file system on the disk
+and offers
+9P (see
+.IR intro (5))
+access to it.
+.I Kfs
+begins by
+checking the file system for consistency,
+rebuilding the free list, and placing a file descriptor in
+.BI /srv/ name\f1,
+where
+.I name
+is the service name (default
+.BR kfs ).
+If the file system is inconsistent,
+the user is asked for permission to ream
+.RI ( q.v. )
+the disk.
+The file system is not checked if it is reamed.
+.PP
+The options are
+.TF "n name"
+.TP
+.BI "b " n
+If the file system is reamed, use
+.I n
+byte blocks.
+Larger blocks make the file system faster
+and less space efficient.
+.B 1024
+and
+.B 4096
+are good choices.
+.I N
+must be a multiple of 512.
+.TP
+.B c
+Do not check the file system.
+.TP
+.BI "f " file
+Use
+.I file
+as the disk.
+The default is 
+.BR /dev/sdC0/fs .
+.TP
+.BI "n " name
+Use
+.RI kfs. name
+as the name of the service.
+.TP
+.BI "p " perm
+Use
+.I perm
+as the initial permissions for the
+command channel
+.BI /srv/ service .cmd\fR;
+the default is 660.
+.TP
+.B r
+Ream the file system, erasing all of the old data
+and adding all blocks to the free list.
+.TP
+.B s
+Post file descriptor zero in
+.BI /srv/ service
+and read and write protocol messages on file descriptor one.
+.TP
+.B B
+Allocate 
+.I nbuf
+in-memory file system blocks.
+The default is as many as will fit in 10% of memory
+or two megabytes, whichever is smaller.
+.PD
+.SH EXAMPLES
+Create a file system with service name
+.I kfs.local
+and mount it on
+.BR /n/kfs .
+.IP
+.EX
+% disk/kfs -rb4096 -nlocal
+% mount -c /srv/kfs.local /n/kfs
+.EE
+.PP
+.SH FILES
+.TF /dev/sdC0/fs
+.TP
+.B /dev/sdC0/fs
+Default file holding blocks.
+.SH SOURCE
+.B /sys/src/cmd/disk/kfs
+.SH "SEE ALSO"
+.IR fossil (4),
+.IR kfscmd (8),
+.IR mkfs (8),
+.IR prep (8),
+.IR sd (3)
+.SH BUGS
+For the moment,
+.I kfs
+serves both the old (third edition) and new (fourth
+edition) versions of 9P, deciding which to serve by sniffing the first packet on each
+connection.
+.LP
+.I Kfs
+doesn't allow creating files with component names longer than 28 bytes.
diff --git a/sys/man/4/lnfs b/sys/man/4/lnfs
new file mode 100755
index 000000000..7f01698fa
--- /dev/null
+++ b/sys/man/4/lnfs
@@ -0,0 +1,64 @@
+.TH LNFS 4
+.SH NAME
+lnfs \- long name file system
+.SH SYNOPSIS
+.B lnfs
+[
+.B -r
+]
+[
+.B -s
+.I srvname
+]
+.I mountpoint
+.br
+.B unlnfs
+.I mountpoint
+.SH DESCRIPTION
+.I Lnfs
+starts a process that mounts itself (see
+.IR bind (2))
+on
+.IR mountpoint .
+It presents a filtered view of the files under the mount
+point, allowing users to use long file names
+on file servers that do not support file names
+longer than 27 bytes.
+.PP
+The names used in the underlying file system are
+the base32 encoding of the md5 hash of the longer
+file name.  The user need not know the mapping
+since
+.I lnfs
+does all the work.
+.I Lnfs
+maintains a file
+.B .longnames
+in the directory
+.I mountpoint
+to record the long file names.
+.PP
+The options are:
+.TP
+.B -r
+allow only read access to the file system
+.TP
+.B -s
+provide a service name,
+.IR srvname ,
+to post in
+.BR /srv .
+Without this option, no posting is performed.
+.PP
+.I Unlnfs
+renames files with shortened names to their actual long names.
+It is useful once you have moved to a file server with true long name support.
+.SH FILES
+.B .longnames
+.SH SOURCE
+.B /sys/src/cmd/lnfs.c
+.PP
+.B /sys/src/cmd/unlnfs.c
+.SH BUGS
+This exists only to shame us into getting a real long
+name file server working.
diff --git a/sys/man/4/mntgen b/sys/man/4/mntgen
new file mode 100755
index 000000000..e4a7c56b1
--- /dev/null
+++ b/sys/man/4/mntgen
@@ -0,0 +1,30 @@
+.TH MNTGEN 4
+.SH NAME
+mntgen  \-  automatically generate mount points for file systems
+.SH SYNOPSIS
+.B mntgen
+[
+.B -s
+.I service
+]
+[
+.I mnt
+]
+.SH DESCRIPTION
+.I Mntgen
+mounts itself on
+.I mnt
+(default
+.BR /n )
+after the current contents,
+creating subdirectories on demand as they are accessed.
+It is intended to supply mount points automatically.
+.PP
+The
+.B -s
+option causes
+.I mntgen
+to post a 9P service file in
+.BI /srv/ service \fR.
+.SH SOURCE
+.B /sys/src/cmd/mntgen.c
diff --git a/sys/man/4/namespace b/sys/man/4/namespace
new file mode 100755
index 000000000..8fd6e429c
--- /dev/null
+++ b/sys/man/4/namespace
@@ -0,0 +1,404 @@
+.TH NAMESPACE 4
+.SH NAME
+namespace \- structure of conventional file name space
+.SH SYNOPSIS
+none
+.SH DESCRIPTION
+After a user's profile has run, the file name space should adhere
+to a number of conventions if the system is to behave normally.
+This manual page documents those conventions by traversing the
+file hierarchy and describing the points of interest.
+It also serves as a guide to where things reside in the file system proper.
+The traversal is far from exhaustive.
+.PP
+First, here is the appearance of the file server as it appears before
+any mounts or bindings.
+.TF /sys/src/cmd
+.TP
+.B /
+The root directory.
+.TP
+.B /adm
+The administration directory for the file server.
+.TP
+.B /adm/users
+List of users known to the file server; see
+.IR users (6).
+.TP
+.B /adm/keys
+Authentication keys for users.
+.TP
+.B /adm/netkeys
+SecureNet keys for users; see
+.IR securenet (8).
+.TP
+.B /adm/timezone
+Directory of timezone files; see
+.IR ctime (2).
+.TP
+.B /adm/timezone/EST.EDT
+Time zone description for Eastern Time.  Other such files are in this directory too.
+.TP
+.B /adm/timezone/timezone
+Time zone description for the local time zone; a copy of one of the other files in this directory.
+.TP
+.B /bin
+.TP
+.B /dev
+.TP
+.B /env
+.TP
+.B /fd
+.TP
+.B /net
+.TP
+.B /proc
+.TP
+.B /srv
+.TP
+.B /tmp
+All empty unwritable directories, place holders for mounted services and directories.
+.TP
+.B /mnt
+A directory containing mount points for applications.
+.TP
+.B /n
+A directory containing mount points for file trees imported from
+remote systems.
+.TP
+.B /386
+.TP
+.B /68000
+.TP
+.B /68020
+.TP
+.B /alpha
+.TP
+.B /arm
+.TP
+.B /mips
+.TP
+.B /power
+.TP
+.B /sparc
+Each CPU architecture supported by Plan 9 has a directory in the root containing
+architecture-specific files, to be selected according to
+.B $objtype
+or
+.B $cputype
+(see
+.IR 2c (1)
+and
+.IR init (8)).
+Here we list only those for
+.BR /386 .
+.TP
+.B /386/init
+The initialization program used during bootstrapping; see
+.IR init (8).
+.TP
+.B /386/bin
+Directory containing binaries for the Intel x86 architecture.
+.TP
+.B "/386/bin/aux
+.TP
+.B /386/bin/ip
+.TP
+etc.
+Subdirectories of
+.B /386/bin
+containing auxiliary tools and collecting related programs.
+.TP
+.B /386/lib
+Directory of object code libraries as used by
+.B 8l
+(see
+.IR 2l (1)).
+.TP
+.B /386/include
+Directory of x86-specific C include files.
+.TP
+.B /386/9*
+The files in
+.B /386
+beginning with a
+.B 9
+are binaries of the operating system or its bootstrap loader.
+.TP
+.B /386/mkfile
+Selected by
+.IR mk (1)
+when
+.B $objtype
+is
+.BR 386 ,
+this file configures
+.B mk
+to compile for the Intel x86 architecture.
+.TP
+.B /rc
+Isomorphic to the architecture-dependent directories, this holds executables
+and libraries for the shell,
+.IR rc (1).
+.TP
+.B /rc/bin
+Directory of shell executable files.
+.TP
+.B /rc/lib
+Directory of shell libraries.
+.TP
+.B /rc/lib/rcmain
+Startup code for
+.IR rc (1).
+.TP
+.B /lib
+Collections of data, generally not parts of programs.
+.TP
+.B /lib/mammals
+.TP
+.B /lib/sky
+.TP
+etc.
+Databases.
+.TP
+.B /lib/ndb
+The network database used by the networking software; see
+.IR ndb (6)
+and
+.IR ndb (8).
+.TP
+.B /lib/namespace
+The file used by
+.B newns
+(see
+.IR auth (2))
+to establish the default name space; see
+.IR namespace (6).
+.TP
+.B /lib/font/bit
+Bitmap font files.
+.TP
+.B /lib/font/hershey
+Vector font files.
+.TP
+.B /lib/rfc
+Directory of Internet `Requests For Comments',
+ranging from trivia to specifications.
+.TP
+.B /lib/rfc/grabrfc
+Maintains RFC collection; usually run from
+.IR cron
+(see
+.IR auth (8)).
+.TP
+.B /sys
+System software.
+.TP
+.B /sys/include
+Directory of machine-independent C include files.
+.TP
+.B /sys/lib
+Pieces of programs not easily held in the various
+.BR bins .
+.TP
+.B /sys/lib/acid
+Directory of
+.IR acid (1)
+load modules.
+.TP
+.B /sys/lib/dist
+Software used to assemble the distribution's installation floppy.
+.TP
+.B /sys/lib/troff
+Directory of
+.IR troff (1)
+font tables and macros.
+.TP
+.B /sys/lib/yaccpar
+The
+.IR yacc (1)
+parser.
+.TP
+.B /sys/man
+The manual.
+.TP
+.B /sys/doc
+Other system documentation.
+.TP
+.B /sys/log
+Log files created by various system services.
+.TP
+.B /sys/src
+Top-level directory of system sources.
+.TP
+.B /sys/src/cmd
+Source to the commands in the
+.B bin
+directories.
+.TP
+.B /sys/src/9
+Source to the operating system for terminals and CPU servers.
+.TP
+.B /sys/src/fs
+Source to the operating system for file servers.
+.TP
+.B /sys/src/lib*
+Source to the libraries.
+.TP
+.B /usr
+A directory containing home directories of users.
+.TP
+.B /mail
+Directory of electronic mail; see
+.IR mail (1).
+.TP
+.B /mail/box
+Directory of users' mail box files.
+.TP
+.B /mail/lib
+Directory of alias files, etc.
+.TP
+.B /acme
+Directory of tools for
+.IR acme (1).
+.TP
+.B /cron
+Directory of files for
+.IR cron (8).
+.TP
+.BI /cfg/ system
+.IR System -specific
+files, often addenda to their namesakes,
+notably
+.BR cpurc ,
+.BR termrc ,
+.BR namespace ,
+and
+.BR consoledb .
+.PD
+.PP
+The following files and directories are modified in the standard
+name space, as defined by
+.B /lib/namespace
+(see
+.IR namespace (6)).
+.TF /sys/src/cmd
+.TP
+.B /
+The root of the name space.  It is a kernel device,
+.IR root (3),
+serving a number of local mount points such as
+.B /bin
+and
+.B /dev
+as well as the bootstrap program
+.BR /boot .
+Unioned with
+.B /
+is the root of the main file server.
+.TP
+.B /boot
+Compiled into the operating system kernel, this file establishes
+the connection to the main file server and starts
+.BR init ;
+see
+.IR boot (8)
+and
+.IR init (8).
+.TP
+.B /bin
+Mounted here is a union directory composed of
+.BR /$objtype/bin ,
+.BR /rc/bin ,
+.BR $home/$objtype/bin ,
+etc., so
+.B /bin
+is always the directory containing the appropriate executables
+for the current architecture.
+.TP
+.B /dev
+Mounted here is a union directory containing I/O devices such as the
+console
+.RI ( cons (3)),
+the interface to the raster display
+.RI ( draw (3)),
+etc.
+The window system,
+.IR rio (1),
+prefixes
+this directory with its own version,
+overriding many device
+files with its own, multiplexed simulations of them.
+.TP
+.B /env
+Mounted here is the environment device,
+.IR env (3),
+which holds environment variables such as
+.BR $cputype .
+.TP
+.B /net
+Mounted here is a union directory formed of all the network devices
+available.
+.TP
+.B /net/cs
+The communications point for the connection server,
+.B ndb/cs
+(see
+.IR ndb (8)).
+.TP
+.B /net/dns
+The communications point for the Domain Name Server,
+.B ndb/dns
+(see
+.IR ndb (8)).
+.TP
+.B /net/tcp
+.TP
+.B /net/udp
+Directories holding the IP protocol devices
+(see
+.IR ip (3)).
+.TP
+.B /proc
+Mounted here is the process device,
+.IR proc (3),
+which provides debugging access to active processes.
+.TP
+.B /fd
+Mounted here is the dup device,
+.IR dup (3),
+which holds pseudonyms for open file descriptors.
+.TP
+.B /srv
+Mounted here is the service registry,
+.IR srv (3),
+which holds connections to file servers.
+.TP
+.B /srv/boot
+The communication channel to the main file server for the machine.
+.TP
+.B /mnt/factotum
+Mount point for
+.IR factotum (4).
+.TP
+.B /mnt/wsys
+Mount point for the window system.
+.TP
+.B /mnt/term
+Mount point for the terminal's name space as seen by the CPU server
+after a
+.IR cpu (1)
+command.
+.TP
+.B /n/kremvax
+A place where machine
+.BR kremvax 's
+name space may be mounted.
+.TP
+.B /tmp
+Mounted here is each user's private
+.B tmp, 
+.BR $home/tmp .
+.SH SEE ALSO
+.IR intro (1),
+.IR namespace (6)
diff --git a/sys/man/4/nfs b/sys/man/4/nfs
new file mode 100755
index 000000000..b1499bb3c
--- /dev/null
+++ b/sys/man/4/nfs
@@ -0,0 +1,210 @@
+.TH NFS 4
+.SH NAME
+nfs \- Sun network file system client
+.SH SYNOPSIS
+.B nfs
+[
+.B -DRv
+]
+[
+.B -p
+.I perm
+]
+[
+.B -s
+.I srvname
+]
+[
+.B -u
+.I passwd
+.I group
+]
+.I addr1
+[
+.I addr2
+]
+.PP
+.B aux/portmap
+[
+.B -R
+]
+.I host
+.I cmd
+...
+.PP
+.B aux/nfsmount
+[
+.B -R
+]
+.I host
+.I cmd
+...
+.SH DESCRIPTION
+.I Nfs
+translates between the Sun network file system protocol (NFS)
+and 9P, allowing 9P clients to mount file systems on NFS servers.
+NFS servers comprise two separate services: a mount service used to
+obtain the initial file handle, and a file service used to perform
+actual file system operations.
+The Sun port mapper service is typically used to find these two services.
+If one address is given, it is taken to be the address of a port mapper service;
+.I nfs
+queries the port mapper to find the addresses
+of the NFS mount service and file service.
+If two addresses are given, the port mapper is bypassed;
+.I addr1
+is used as the address of the NFS mount service,
+and
+.I addr2
+is used as the address of the file service.
+.PP
+The options are:
+.TP
+.B -D
+print all 9P messages.
+.TP
+.B -R
+print all NFS messages.
+.TP
+.B -v
+print verbose information about session startup.
+.TP
+.B -p \fIperm
+set the posted service file to have mode
+.IR perm ,
+which is assumed to be octal;
+the default is
+.BR 600 .
+.TP
+.B -s \fIsrvname
+post the service as
+.BI /srv/ srvname \fR;
+the default is
+.BI /srv/ addr1 \fR.
+.TP
+.B -u \fIpasswd\fR \fIgroup
+translate user and group names using the 
+.I passwd
+and
+.I group
+files, which are in the traditional Unix format.
+The translation is used to present names for
+user and group in
+.IR stat (5)
+and
+.I wstat
+messages.
+The translation is also used to
+choose the user and group credentials
+to present for a user.
+Without this option, users and groups are presented
+as decimal numbers, and everyone attaches as uid \-1
+.RB ( nobody
+on most Unix systems).
+.PP
+.I Portmap
+and
+.I nfsmount
+are test programs to perform port mapper and NFS mount RPCs.
+They
+are useful mainly to help debug problems with
+starting 
+.I nfs
+itself.
+The 
+.B -R
+option causes them to print all RPC messages sent and received.
+.PP
+.I Portmap
+queries a Sun RPC portmap server, which maps integer
+(program, version, protocol) triples to port numbers.
+Program and version are Sun RPC defined, while protocol
+is typically TCP (6) or UDP (17).
+The commands are:
+.TP
+.B null
+a no-op
+.TP
+.B dump
+print the entire map
+.TP
+.B set \fIprog\fP \fIvers\fP \fIproto\fP \fIport\fP
+add an entry to (or replace an entry in) the map
+.TP
+.B unset \fIprog\fP \fIvers\fP \fIproto\fP \fIport\fP
+remove an entry from the map
+.TP
+.B getport \fIprog\fP \fIvers\fP \fIproto\fP
+look for an entry with \fIprog\fP, \fIvers\fP, \fIproto\fP
+in the map, and return the corresponding port
+.PD
+The default command is
+.BR dump .
+For running NFS over UDP, there must be an entry
+for the NFS v3 mount daemon (100005, 3, 17) and the
+NFS v3 server itself (100003, 3, 17).  
+.PP
+.I Nfsmount
+queries a Sun NFS mount server, which authenticates (ha!)
+connections and hands out file handles naming the root of
+an exported file system.  This handle is used as the basis
+for a conversation with the NFS service daemon itself.
+The commands are:
+.TP
+.B null
+a no-op
+.TP
+.B export
+dump the export table;
+each line is a path followed by a list of machines or groups
+allowed to mount that path
+.TP
+.B mnt \fIpath\fR
+attempt to acquire a file handle for \fIpath\fR.
+the request has user and group id 1001 and
+.L gnot
+as the system name.
+.TP
+.B umnt \fIpath\fR
+notify the mount daemon that a particular path is being
+unmounted by the requesting system
+.TP
+.B umntall
+notify the mount daemon that all paths mounted by the
+requesting system are being unmounted
+.TP
+.B dump
+should also dump an export table, but typically 
+does nothing
+.PD
+.SH EXAMPLE
+We use this in our
+.B /rc/bin/9fs
+script to mount all the home directories served by
+.IR bopp :
+.IP
+.EX
+case bopp
+	if(! test -f /srv/bopp)
+		nfs -p 666 -u /lib/ndb/1127.passwd /lib/ndb/1127.group bopp
+	unmount /n/bopp >[2]/dev/null
+	for(i in u0 u1 u2 u3 u4 u5 u6 u7 u8 u9)
+		mount -a /srv/bopp /n/bopp /$i
+.EE
+.SH SOURCE
+.B /sys/src/cmd/nfs.c
+.br
+.B /sys/src/libsunrpc
+.SH "SEE ALSO
+.IR nfsserver (8),
+.IR srv (4)
+.SH BUGS
+The authentication employed by NFS is laughable.
+The server simply trusts the uid, gid, and group list
+presented by the client.
+.PP
+.I Nfs
+speaks only NFS version 3.
+Older operating systems typically
+have reasonable NFS version 2 servers
+but crash when serving version 3.
diff --git a/sys/man/4/nntpfs b/sys/man/4/nntpfs
new file mode 100755
index 000000000..bb066289c
--- /dev/null
+++ b/sys/man/4/nntpfs
@@ -0,0 +1,136 @@
+.TH NNTPFS 4
+.SH NAME
+nntpfs \- network news transport protocol (NNTP) file system
+.SH SYNOPSIS
+.B nntpfs
+[
+.B -a
+]
+[
+.B -s
+.I service
+]
+[
+.B -m
+.I mountpoint
+]
+[
+.I system
+]
+.SH DESCRIPTION
+.I Nntpfs
+dials the TCP network news transport protocol (NNTP)
+port, 119, on
+.I system
+(default
+.BR '$nntp' )
+and presents at
+.I mountpoint
+(default
+.BR /mnt/news )
+a file system corresponding to the
+news articles stored on 
+.IR system .
+.PP
+If the
+.B -s
+option is given, the file system is posted as
+.BI /srv/ service \fR.
+If the
+.B -a
+option is given,
+.I nntpfs
+authenticates to the system with a user name and password
+obtained from
+.IR factotum (4).
+The key specifier is
+.IP
+.B
+proto=pass service=nntp server=\fIserver\fR user? !password?
+.PP
+The file system contains a directory per newsgroup,
+with dots turned into slashes, e.g.,
+.B comp/os/plan9
+for
+.BR comp.os.plan9 .
+Each newsgroup directory contains one
+numbered directory per article.
+The directories follow the numbering used by
+the server.
+Each article directory contains three files:
+.BR article ,
+.BR header ,
+and
+.BR body .
+The
+.B article
+file contains the full text of the article,
+while 
+.B header
+and 
+.B body
+contain only the header or body.
+.PP
+Each newsgroup directory contains a 
+write-only
+.B post
+file that may be used to post news articles.
+RFC1036-compliant articles should be written to it.
+The
+.B post
+file will only exist in a given newsgroup directory
+if articles are allowed to be posted to it.
+Other than that, the
+.B post
+file is
+.I not
+tied to its directory's newsgroup.
+The groups to which articles are eventually posted
+are determined by the
+.B newsgroups:
+header lines in the posted article,
+not by the location of the 
+.B post
+file in the file system.
+.PP
+The qid version of a newsgroup directory
+is the largest numbered article directory it
+contains (~0, if there are no articles).
+.PP
+The modification time on a newsgroup
+directory is the last time a new article was recorded
+during this 
+.I nntpfs 
+session.
+To force a check for new articles,
+.IR stat (2)
+the newsgroup directory.
+.PP
+To force a check for new newsgroups,
+.IR stat (2)
+the root directory.
+Note that this causes the entire list of groups,
+which can be about a megabyte,
+to be transferred.
+.PP
+To terminate the connection,
+.B unmount
+the mount point.
+.PP
+.I Nntpfs
+makes no effort to send ``keepalives'' so that
+servers do not hang up on it.
+Instead, it redials as necessary when hangups are detected.
+.SH EXAMPLE
+Authenticate to a private news server:
+.IP
+.EX
+% echo key proto=pass service=nntp server=nose.mit.edu \e
+	user=rsc !password=secret >/mnt/factotum/ctl
+% nntpfs -a nose.mit.edu
+.EE
+.SH SOURCE
+.B /sys/src/cmd/nntpfs.c
+.SH BUGS
+Directories are presented for deleted articles;
+the files in them cannot be opened.
diff --git a/sys/man/4/paqfs b/sys/man/4/paqfs
new file mode 100755
index 000000000..59fe6f99a
--- /dev/null
+++ b/sys/man/4/paqfs
@@ -0,0 +1,102 @@
+.TH PAQFS 4
+.SH NAME
+paqfs  \- compressed read-only file system
+.SH SYNOPSIS
+.B paqfs
+[
+.B -disv
+]
+[
+.B -c
+.I cachesize
+]
+[
+.B -m
+.I mtpt
+]
+[
+.B -M
+.I mesgsize
+]
+[
+.B -S
+.I srvname
+]
+.I paqfile
+.SH DESCRIPTION
+.I Paqfs
+interprets the compressed read-only file system created by
+.IR mkpaqfs (8)
+and stored in
+.I paqfile
+so that it can be mounted into a Plan 9 file system.
+.I Paqfs
+is typically used to create a stand alone file system for
+a small persistent storage device, such as a flash ROM.
+It does not authenticate its clients and assumes each group
+has a single member with the same name.
+.PP
+Options to 
+.I paqfs
+are:
+.TP
+.BI -c " cachesize
+The number of file system blocks to cache in memory. The default is 20 blocks.
+.TP
+.BI -M " mesgsize
+The maximum 9P message size. The default is sufficient for 8K byte read message.
+.TP
+.B -d
+Output various debugging information to
+.IR stderr .
+.TP
+.B -i
+Use file descriptors 0 and 1 as the 9P communication channel rather than create a pipe.
+.TP
+.B -q
+Suppress the output of the archive creation date and fingerprint to
+.IR stderr .
+.TP
+.BI -m " mtpt
+The location to mount the file system. The default is
+.BR /n/paq .
+.TP
+.B -s
+Post the 9P channel on
+.BR #s/\fIsrvname\fR ,
+default
+.BR #s/paqfs ,
+rather than
+mounting it on
+.IR mtpt .
+.TP
+.B -S
+The name to post in
+.BR #s .
+The default is
+.BR paqfs .
+.TP
+.B -p
+Both post the 9P channel in
+.B #s
+and
+mount the
+.I paqfile
+in to the filesystem.
+.TP
+.B -v
+Verify the integrity of the
+.IR paqfile .
+Before mounting the file system, the
+entire file is parsed and the 
+.I sha1
+checksum of the file system data is compared to the checksum embedded in the file.
+This option enables the use of
+.I paqfs
+with files that consist of a 
+.I paq
+file system concatenated with additional data.
+.SH SOURCE
+.B /sys/src/cmd/paqfs/paqfs.c
+.SH "SEE ALSO"
+.IR mkpaqfs (8)
diff --git a/sys/man/4/plumber b/sys/man/4/plumber
new file mode 100755
index 000000000..fbaebe419
--- /dev/null
+++ b/sys/man/4/plumber
@@ -0,0 +1,126 @@
+.TH PLUMBER 4
+.SH NAME
+plumber \- file system for interprocess messaging
+.SH SYNOPSIS
+.B plumber
+[
+.B -p
+.I plumbing
+]
+.SH DESCRIPTION
+The
+.I plumber
+is a user-level file server that receives, examines, rewrites, and dispatches
+.IR plumb (6)
+messages between programs.
+Its behavior is programmed by a
+.I plumbing
+file (default
+.BR /usr/$user/lib/plumbing )
+in the format of
+.IR plumb (6).
+.PP
+Its services are mounted on the directory
+.B /mnt/plumb
+.RB ( /mnt/term/mnt/plumb
+on the CPU server) and consist of two
+pre-defined files,
+.B send
+and
+.BR rules ,
+and a set of output
+.I ports
+for dispatching messages to applications.
+The service is also published as a
+.IR srv (4)
+file, named in
+.BR $plumbsrv ,
+for mounting elsewhere.
+.PP
+Programs use
+.B write
+(see
+.IR read (2))
+to deliver messages to the
+.B send
+file, and
+.IR read (2)
+to receive them from the corresponding port.
+For example,
+.IR sam (1)'s
+.B plumb
+menu item or the
+.B B
+command cause a message to be sent to
+.BR /mnt/plumb/send ;
+.B sam
+in turn reads from, by convention,
+.B /mnt/plumb/edit
+to receive messages about files to open.
+.PP
+A copy of each message is sent to each client that has the corresponding port open.
+If none has it open, and the rule has a
+.B plumb
+.B client
+or
+.B plumb
+.B start
+rule, that rule is applied.
+A
+.B plumb
+.B client
+rule causes the specified command to be run
+and the message to be held for delivery when the port is opened.
+A
+.B plumb
+.B start
+rule runs the command but discards the message.
+If neither
+.B start
+or
+.B client
+is specified and the port is not open,
+the message is discarded and a write error is returned to the sender.
+.PP
+The set of output ports is determined dynamically by the
+specification in the plumbing rules file: a port is created for each unique
+destination of a
+.B plumb
+.B to
+rule.
+.PP
+The set of rules currently active may be examined by reading the file
+.BR /mnt/plumb/rules ;
+appending to this file adds new rules to the set, while
+creating it (opening it with
+.BR OTRUNC )
+clears the rule set.
+Thus the rule set may be edited dynamically with a traditional text editor.
+However, ports are never deleted dynamically; if a new set of rules does not
+include a port that was defined in earlier rules, that port will still exist (although
+no new messages will be delivered there).
+.SH FILES
+.TF /usr/$user/lib/plumbing
+.TP
+.B /usr/$user/lib/plumbing
+default rules file
+.TP
+.B /sys/lib/plumb
+directory to search for files in
+.B include
+statements
+.TP
+.B /mnt/plumb
+mount point for
+.IR plumber (4).
+.SH SOURCE
+.B /sys/src/cmd/plumb
+.SH "SEE ALSO"
+.IR plumb (1),
+.IR plumb (2),
+.IR plumb (6)
+.SH BUGS
+.IR Plumber 's
+file name space is fixed, so it is difficult to plumb
+messages that involve files in newly mounted services.
+
diff --git a/sys/man/4/ramfs b/sys/man/4/ramfs
new file mode 100755
index 000000000..94f69c519
--- /dev/null
+++ b/sys/man/4/ramfs
@@ -0,0 +1,89 @@
+.TH RAMFS 4
+.SH NAME
+ramfs  \- memory file system
+.SH SYNOPSIS
+.B ramfs
+[
+.B -Dipsu
+]
+[
+.B -m
+.I mountpoint
+]
+[
+.B -S
+.I srvname
+]
+.SH DESCRIPTION
+.I Ramfs
+starts a process that mounts itself (see
+.IR bind (2))
+on
+.I mountpoint
+(default
+.BR /tmp ).
+The
+.I ramfs
+process implements a file tree rooted at
+.IR dir ,
+keeping all files in memory.
+Initially the file tree is empty.
+.PP
+The
+.B -D
+option enables a trace of general debugging messages.
+.PP
+The
+.B -i
+flag tells
+.I ramfs
+to use file descriptors 0 and 1 for its communication channel
+rather than create a pipe.
+This makes it possible to use
+.I ramfs
+as a file server on a remote machine: the file descriptors 0
+and 1 will be the network channel from
+.I ramfs
+to the client machine.
+.PP
+The
+.B -p
+flag causes
+.I ramfs
+to make its memory `private'
+(see
+.IR proc (3))
+so that its files are not accessible through the debugging interface.
+.PP
+The
+.B -s
+.RB ( -S )
+flag causes
+.I ramfs
+to post its channel on
+.B /srv/ramfs
+.RB ( /srv/ \fIsrvname\fR)
+rather than mounting it on
+.IR mountpoint ,
+enabling multiple clients to access its files.
+However, it does not authenticate its clients and its
+implementation of groups is simplistic, so
+it should not be used for precious data.
+.PP
+The
+.B -u
+option permits
+.I ramfs
+to consume as much memory as needed;
+without it,
+.I ramfs
+will limit its consumption to some arbitrary amount,
+currently 768MB (enough to hold a CD image).
+.PP
+This program is useful mainly as an example of how
+to write a user-level file server.
+It can also be used to provide high-performance temporary files.
+.SH SOURCE
+.B /sys/src/cmd/ramfs.c
+.SH "SEE ALSO"
+.IR bind (2)
diff --git a/sys/man/4/ratfs b/sys/man/4/ratfs
new file mode 100755
index 000000000..0820cf7c5
--- /dev/null
+++ b/sys/man/4/ratfs
@@ -0,0 +1,174 @@
+.TH RATFS 4
+.SH NAME
+ratfs  \- mail address ratification file system
+.SH SYNOPSIS
+.B ratfs
+[
+.B -d
+] [
+.B -c
+.I configuration
+] [
+.B -f
+.I classification
+] [
+.B -m
+.I mountpoint
+]
+.SH DESCRIPTION
+.I Ratfs
+starts a process that mounts itself (see
+.IR bind (2))
+on
+.I mountpoint
+(default
+.BR /mail/ratify ).
+.I Ratfs
+is a persistent representation of the local network
+configuration and spam blocking list.  Without it
+each instance of
+.IR smtpd (6)
+would need to reread and parse a multimegabyte list
+of addresses and accounts.
+.PP
+.I Ratfs
+serves a control file,
+.BR ctl ,
+and several top level directories:
+.BR trusted ,
+.BR deny ,
+.BR dial ,
+.BR block ,
+.BR delay ,
+and
+.BR allow .
+.PP
+The control file is write only and accepts three
+possible commands:
+.TF "debug file
+.TP
+.B reload
+rereads
+.I classification
+and
+.I configuration
+.TP
+.B debug \fIfile\fP
+creates
+.I file
+and sends debugging output to it.
+.TP
+.B nodebug
+closes the debug file and turns off debugging
+.PD
+.PP
+The directory
+.B trusted
+serves a file for each IP range from which all mail
+is trusted.  The names of the files are CIDR blocks;
+an IP address or an IP address followed by
+.BR #\fIn\fP ,
+where
+.I n
+is the number of bits to match.
+To check if any IP address falls in a trusted
+range, it is sufficient to open the file whose
+name is the IP address.
+For example, if
+.B trusted
+contains only the file
+.BR 135.104.0.0#16 ,
+an attempt to open the file 135.104.9.1 will
+succeed while opening 10.1.1.1 will fail.
+To determine the particular range matched,
+.B dirfstat
+(see stat (2))
+the open file and the
+.B name
+field will be the matching CIDR range.
+.PP
+The trusted ranges come both from the
+.B ournet
+entries in the file
+.I configuration
+(default
+.BR /mail/lib/blocked )
+and from creates, typically done by
+.B imap4d
+(see
+.IR ipserv (8))
+and
+.B pop3
+(see
+.IR mail (1))
+whenever they are used to read someone's mail.
+.PP
+The remaining directories,
+.BR allow ,
+.BR block ,
+.BR delay ,
+.BR deny ,
+and
+.BR dial ,
+represent the contents of the
+.I classification 
+(default
+.BR /mail/lib/smtpd.conf.ext ).
+Each contains two directories;
+.B ip
+and
+.BR account .
+The
+.B ip
+directory has the same open semantics as the 
+.B trusted
+directory, i.e., to check if an IP address falls
+in that category, try to open a file whose
+name is the IP address.
+The
+.B account
+directory is similar but is used for matching
+strings.  Each file in the directory represents
+a regular expression.  To see if one of the
+strings matches one of the regular expressions,
+try to open the file whose name is the string.
+If it succeeds, then there is a regular expression
+that matches.  To determine the regular expression,
+.B fstat
+the open file.  The
+.B name
+field will be the regular expression.
+.PP
+There is a direct mapping from entries in
+.I classification
+and files under
+.BR allow ,
+.BR block ,
+.BR delay ,
+.BR deny ,
+and
+.BR dial.
+A configuration file entry of the form:
+.EX
+	dial	135.104.9.0/24
+.EE
+corresponds to the file
+.BR dial/ip/135.104.9.0#24 .
+An entry of the form
+.EX
+	*block	.*!gre
+.EE
+corresponds to the file
+.BR block/account/.*!gre .
+.PP
+Both the configuration file and control file formats
+are described in
+.IR smtpd (6).
+.SH SOURCE
+.B /sys/src/cmd/ratfs
+.SH "SEE ALSO"
+.IR mail (1)
+.IR smtpd (6)
+.IR scanmail (8)
+
+
diff --git a/sys/man/4/rdbfs b/sys/man/4/rdbfs
new file mode 100755
index 000000000..383dd26c7
--- /dev/null
+++ b/sys/man/4/rdbfs
@@ -0,0 +1,67 @@
+.TH RDBFS 4
+.SH NAME
+rdbfs \- remote kernel debugging file system
+.SH SYNOPSIS
+.B rdbfs
+[
+.B -d
+]
+[
+.B -p 
+.I pid
+]
+[
+.B -t
+.I text
+]
+[
+.I device
+]
+.SH DESCRIPTION
+.I Rdbfs
+presents in 
+.BI /proc/ pid
+(default
+.BR /proc/1 )
+a set of process files for debugging
+a kernel over the serial line 
+.I device
+(default 
+.BR /dev/eia0 ).
+.PP
+The 
+.B text
+file presented is just a copy of
+.I text
+(default
+.BR /386/9pc ).
+It can usually be ignored, since
+the debuggers open kernel
+files directly rather than
+using
+.BI /proc/ n /text\fR.
+.PP
+Kernels can be remotely debugged  only when they are
+suspended and serving
+a textual debugging protocol over their serial lines.
+Typing 
+.RB `` ^t^td ''
+.RB (control- t ", control-" t ", d)"
+at the console will cause the kernel to enter
+this mode when it `panics'.
+Typing 
+.RB `` ^t^tD '' 
+causes the kernel to enter this mode immediately.
+.PP
+Because the debugging protocol is textual, a console
+provided by
+.IR consolefs (4)
+may be substituted for the serial device.
+.SH SOURCE
+.B /sys/src/cmd/rdbfs.c
+.br
+.B /sys/src/9/port/rdb.c
+.SH "SEE ALSO"
+.IR acid (1),
+.IR db (1),
+.IR consolefs (4)
diff --git a/sys/man/4/rio b/sys/man/4/rio
new file mode 100755
index 000000000..1bcd94362
--- /dev/null
+++ b/sys/man/4/rio
@@ -0,0 +1,407 @@
+.TH RIO 4
+.SH NAME
+rio \- window system files
+.SH SYNOPSIS
+.B rio
+[
+.B -i
+.BI ' cmd '
+]
+[
+.B -s
+]
+[
+.B -f
+.I font
+]
+.SH DESCRIPTION
+The window system
+.I rio
+serves a variety of files for reading, writing, and controlling
+windows.
+Some of them are virtual versions of system files for dealing
+with the display, keyboard, and mouse; others control operations
+of the window system itself.
+.I Rio
+posts its service in the
+.B /srv
+directory, using a
+name constructed from a catenation of the user ID
+and a process id; the environment variable
+.BR $wsys
+is set to this service name within processes running under the control
+of each invocation of
+.IR rio .
+Similarly,
+.I rio
+posts a named pipe to access the window creation features
+(see
+.B window
+in
+.IR rio (1))
+from outside
+its name space; this is named in
+.BR $wctl .
+.PP
+A
+.I mount
+(see
+.IR bind (1))
+of
+.B $wsys
+causes
+.I rio
+to create a new window; the attach specifier in the
+.I mount
+gives the coordinates of the created window.
+The syntax of the specifier is the same as the arguments to
+.B window
+(see
+.IR rio (1)).
+By default, the window is sized and placed automatically.
+It is always necessary, however, to provide the process id of the
+process to whom to deliver notes generated by DEL characters and hangups
+in that window.
+That pid is specified by including the string
+.B -pid
+.I pid
+in the attach specifier.  (See the Examples section
+.IR q.v. )
+.PP
+When a window is created either by
+the
+.I window
+command
+(see
+.IR rio (1))
+or by using the menu supplied by
+.IR rio ,
+this server is mounted on
+.BR /mnt/wsys
+and also
+.BR /dev ;
+the files mentioned here
+appear in both those directories.
+.PP
+Some of these files supply virtual versions of services available from the underlying
+environment, in particular the character terminal files
+.IR cons (3),
+and the mouse files
+.IR mouse (3)
+and
+.IR cursor ,
+each specific to the window.
+Note that the
+.IR draw (3)
+device multiplexes itself;
+.IR rio
+places windows but does not mediate programs' access to the display device.
+.PP
+Other files are unique to
+.IR rio .
+.TF window
+.TP
+.B cons
+is a virtual version of the standard terminal file
+.IR cons (3).
+.I Rio
+supplies extra editing features and a scroll bar
+(see
+.IR rio (1)).
+.TP
+.B consctl
+controls interpretation of keyboard input.
+Writing strings to it sets these modes:
+.B rawon
+turns on raw mode;
+.B rawoff
+turns off raw mode;
+.B holdon
+turns on hold mode;
+.B holdoff
+turns off hold mode.
+Closing the file makes the window revert to default state
+(raw off, hold off).
+.TP
+.B cursor
+Like
+.B mouse
+.RI ( q.v. ),
+a multiplexed version of the underlying device file, in this case representing the
+appearance of the mouse cursor when the mouse is within the corresponding window.
+.TP
+.B label
+initially contains a string with the process ID of the lead process
+in the window and the command being executed there.
+It may be written and is used as a tag when the window is hidden.
+.TP
+.B mouse
+is a virtual version of the standard mouse file (see
+.IR mouse (3)).
+Opening it turns off scrolling, editing, and
+.IR rio -supplied
+menus in the associated
+window.
+In a standard mouse message, the first character is
+.BR m ,
+but
+.I rio
+will send an otherwise normal message with the first character
+.B r
+if the corresponding window has been resized.
+The application must then call
+.B getwindow
+(see
+.IR graphics (2))
+to re-establish its state in the newly moved or changed window.
+Reading the
+.B mouse
+file blocks until the mouse moves or a button changes.
+Mouse movements or button changes are invisible when the mouse cursor
+is located outside the window, except that if the mouse leaves the window
+while a button is pressed, it will continue receiving mouse data until the button is released.
+.TP
+.B screen
+is a read-only file reporting the depth, coordinates, and raster image corresponding to the entire
+underlying display,
+in the uncompressed format defined in
+.IR image (6).
+.TP
+.B snarf
+returns the string currently in the snarf buffer.
+Writing this file sets the contents of the snarf buffer.
+When
+.I rio
+is run recursively, the inner instance uses the snarf buffer of the parent, rather than
+managing its own.
+.TP
+.B text
+returns the full contents of the window.
+It may not be written.
+.TP
+.B wctl
+may be read or written.
+When read, it returns the location of the window as four decimal integers formatted
+in the usual 12-character style: upper left
+.I x
+and
+.IR y ,
+lower right
+.I x
+and
+.IR y .
+Following these numbers are strings describing the window's state:
+.B hidden
+or
+.BR visible ;
+.B current
+or
+.BR notcurrent .
+A subsequent read will block until the window changes size, location, or state.
+When written to,
+.B wctl
+accepts messages to change the size or placement of the associated window,
+and to create new windows.
+The messages are in a command-line like format, with a command name,
+possibly followed by options introduced by a minus sign.
+The options must be separated by blanks, for example
+.B -dx 100
+rather than
+.BR -dx100 .
+.IP
+The commands are
+.B resize
+(change the size and position of the window),
+.B move
+(move the window),
+.B scroll
+(enable scrolling in the window),
+.B noscroll
+(disable scrolling),
+.B set
+(change selected properties of the window),
+.B top
+(move the window to the `top', making it fully visible),
+.B bottom
+(move the window to the `bottom', perhaps partially or totally obscuring it),
+.B hide
+(hide the window),
+.B unhide
+(restore a hidden window),
+.B current
+(make the window the recipient of keyboard and mouse input),
+and
+.B new
+(make a new window).
+The
+.B top
+and
+.B bottom
+commands do not change whether the window is current or not;
+the others always make the affected window current.
+.IP
+Neither
+.B top
+nor
+.B bottom
+has any options.
+The
+.BR resize ,
+.BR move ,
+and
+.B new
+commands accept
+.B -minx
+.IR n ,
+.B -miny
+.IR n ,
+.B -maxx
+.IR n ,
+and
+.BR -maxy
+.I n
+options to set the position of the corresponding edge of the window.
+They also accept an option
+.B -r
+.I minx miny maxx maxy
+to set all four at once.
+The
+.B resize
+and
+.B new
+commands accept
+.B -dx
+.I n
+and
+.B -dy
+.I n
+to set the width and height of the window.
+By default,
+.I rio
+will choose a convenient geometry automatically.
+.IP
+Finally, the
+.B new
+command accepts an optional shell command and argument string,
+given as plain strings after any standard options, to run in the window
+instead of the default
+.B rc
+.B -i
+(see
+.IR rc (1)).
+The
+.B -pid
+.I pid
+option to
+.B new
+identifies the
+.I pid
+of the process whose `note group' should receive interrupt
+and hangup notes generated in the window.
+The initial working directory of the new window may be set by a
+.B -cd
+.I directory
+option.
+The
+.B -hide
+option causes the window to be created off-screen, in the hidden state, while
+.B -scroll
+and
+.B -noscroll
+set the initial scrolling state of the window; the default is that of the main program.
+.IP
+The
+.B set
+command accepts a set of parameters in the same style; only
+.B -pid
+.I pid
+is implemented.
+.IP
+So programs outside name spaces controlled by
+.I rio
+may create windows,
+.B wctl
+.B new
+messages may also be written to the named pipe identified by
+.BR $wctl .
+.TP
+.B wdir
+is a read/write text file containing
+.IR rio 's
+idea of the current working directory of the process running in the window.
+It is used to fill in the
+.B wdir
+field of
+.IR plumb (6)
+messages
+.I rio
+generates from the
+.B plumb
+menu item on button 2.
+The file is writable so the program may update it;
+.I rio
+is otherwise unaware of
+.IR chdir (2)
+calls its clients make.
+In particular,
+.IR rc (1)
+maintains
+.B /dev/wdir
+in default
+.IR rio (1)
+windows.
+.TP
+.B winid
+returns the unique and unchangeable ID for the window;
+it is a string of digits.
+.TP
+.B window
+is the virtual version of
+.BR /dev/screen .
+It contains the depth, coordinates, and
+uncompressed raster image corresponding to the associated
+window.
+.TP
+.B wsys
+is a directory containing a subdirectory for each window, named
+by the unique ID for that window.  Within each subdirectory
+are entries corresponding to several of the special files associated
+with that window:
+.BR cons ,
+.BR consctl ,
+.BR label ,
+.BR mouse ,
+etc.
+.SH EXAMPLES
+Cause a window to be created in the upper left corner,
+and the word
+.L hi
+to be printed there.
+.IP
+.EX
+mount $wsys /tmp 'new -r 0 0 128 64 -pid '$pid
+echo hi > /tmp/cons
+.EE
+.PP
+Start
+.IR sam (1)
+in a large horizontal window.
+.IP
+.EX
+echo new -dx 800 -dy 200 -cd /sys/src/cmd sam > /dev/wctl
+.EE
+.PP
+Print the screen image of window with id 123.
+.IP
+.EX
+lp /dev/wsys/123/window
+.EE
+.SH SOURCE
+.B /sys/src/cmd/rio
+.SH SEE ALSO
+.IR rio (1),
+.IR draw (3),
+.IR mouse (3),
+.IR cons (3),
+.IR event (2),
+.IR graphics (2).
diff --git a/sys/man/4/sacfs b/sys/man/4/sacfs
new file mode 100755
index 000000000..9b9662816
--- /dev/null
+++ b/sys/man/4/sacfs
@@ -0,0 +1,59 @@
+.TH SACFS 4
+.SH NAME
+sacfs  \- compressed file system
+.SH SYNOPSIS
+.B disk/sacfs
+[
+.B -i
+.I infd
+.I outfd
+]
+[
+.B -s
+]
+[
+.B -m
+.I mountpoint
+]
+.I file
+.SH DESCRIPTION
+Sacfs interprets the compressed, block based file system created by
+.IR mksacfs (8)
+and stored in
+.I file
+so that it can be mounted into a Plan 9 file system.
+.I Sacfs
+is typically used to create a stand alone file system from
+a small persistent storage device, such as a flash rom.
+It does not authenticate its clients and assumes each group
+has a single member with the same name.
+.PP
+The
+.B -s
+flag causes
+.I sacfs
+to post its channel on
+.BR #s/sacfs .
+The
+.B -i
+flag causes
+.I sacfs
+to use file descriptors
+.I infd
+and
+.I outfd
+for its communication channel.
+If neither
+.B -s
+nor
+.B -i
+are given,
+.I sacfs
+mounts itself on
+.IR mountpoint
+(default
+.BR /n/c: ).
+.SH SOURCE
+.B /sys/src/cmd/disk/sacfs/sacfs.c
+.SH "SEE ALSO"
+.IR mksacfs (8)
diff --git a/sys/man/4/snap b/sys/man/4/snap
new file mode 100755
index 000000000..3db9914f4
--- /dev/null
+++ b/sys/man/4/snap
@@ -0,0 +1,106 @@
+.TH SNAP 4
+.SH NAME
+snap, snapfs \- create and mount process snapshots
+.SH SYNOPSIS
+.B snap 
+[
+.B -o
+.I file
+]
+.I pid...
+.PP
+.B snapfs
+[
+.B -a
+]
+[
+.B -m 
+.I mtpt
+]
+[
+.B -s
+.I service
+]
+.I file...
+.SH DESCRIPTION
+.I Snap
+and 
+.I snapfs
+allow one to save and restore (static) process images,
+usually for debugging
+on a different machine or at a different time.
+.PP
+.I Snap
+writes a snapshot 
+(see 
+.IR snap (6))
+of the named processes to
+.I file 
+(default standard output).
+If 
+.I pid
+is a text string
+rather than a process id,
+.I snap
+will save all processes with
+that name that
+are owned by the current user.
+Both memory and text images are saved.
+.PP
+.I Snapfs
+is a file server that
+recreates the
+.B /proc
+directories for the processes in the snapshot.
+By default, it mounts the new directories
+into 
+.B /proc
+before the current entries.
+The 
+.B -m
+option can be used to specify
+an alternate mountpoint,
+while
+.B -a
+will cause it to mount the new directories
+after the current entries.
+The 
+.B -s
+option causes it to serve requests via
+.BI /srv/ service.
+.SH EXAMPLE
+Suppose
+.I page
+has hung viewing Postscript on your terminal, but the author is gone for the rest of
+the month and you want to make sure the process
+is still around for debugging on his return.
+You can save the errant processes with
+.IP
+.EX
+snap -o page.snap `{psu | awk '$NF ~ /page|gs/ {print $2}'}
+.EE
+.PP
+When the author returns, he can add the process images to his name space
+by running
+.IP
+.EX
+snapfs page.snap
+.EE
+.PP
+and then use a conventional
+debugger to debug them.
+.SH SOURCE
+.B /sys/src/cmd/snap
+.SH SEE ALSO
+.IR acid (1),
+.IR db (1),
+.IR proc (3),
+.IR snap (6)
+.SH BUGS
+The snapshots take up about as much disk space
+as the processes they contain did memory.
+Compressing them when not in use is recommended,
+as is storing them on a rewritable disk.
+.PP
+.I Pid
+as a non-numeric string is unimplemented; it has to be a number.
diff --git a/sys/man/4/srv b/sys/man/4/srv
new file mode 100755
index 000000000..6770de13e
--- /dev/null
+++ b/sys/man/4/srv
@@ -0,0 +1,338 @@
+.TH SRV 4 
+.SH NAME
+srv, srvold9p, 9fs, srvssh \- start network file service
+.SH SYNOPSIS
+.B srv
+[
+.B -abcCemnq
+] [
+.B -s
+.I seconds
+]
+.RI [ net !] system\c
+.RI [! service ]
+[
+.I srvname
+[
+.I mtpt
+] ]
+.PP
+.B srvssh
+[
+.B -r
+]
+[
+.B -R
+]
+[
+.B -s
+]
+[
+.B -u
+.I u9fspath
+]
+.I system
+[
+.I srvname
+[
+.I mtpt
+] ]
+.PP
+.B 9fs
+.RI [ net !] system
+.RI [ mountpoint ]
+.PP
+.in +0.5i
+.ti -0.5i
+.B srvold9p
+[
+.B -abcCdF
+] [
+.B -p
+.I servicename
+] [
+.B -s
+|
+.B -m
+.I mountpoint
+] [
+.B -u
+.I user
+] [
+.B -x
+.I command
+|
+.B -n
+.I network-addr
+|
+.B -f
+.I file
+]
+.br
+.in -0.5i
+.SH DESCRIPTION
+.I Srv
+dials the given machine and initializes the connection to serve the
+9P protocol.
+By default, it connects to the
+.L 9fs
+(9P)
+service, which for TCP is port 564.
+It then creates in
+.B /srv
+a file named
+.IR srvname .
+Users can then
+.B mount
+(see
+.IR bind (1))
+the service, typically on a name in
+.BR /n ,
+to access the files provided by the remote machine.
+If
+.I srvname
+is omitted, the first argument to
+.I srv
+is used.
+Option
+.B m
+directs
+.I srv
+to mount the service on
+.BI /n/ system
+or onto
+.I mtpt
+if it is given.
+Option
+.B q
+suppresses complaints if the
+.B /srv
+file already exists.
+The 
+.BR a ,
+.BR b ,
+.BR c ,
+.BR C ,
+and
+.B n
+options are used to control the mount flags as in
+.I mount
+(see
+.IR bind (1)).
+The
+.B e
+option causes
+.I srv
+to treat
+.I system
+as a shell command to be executed rather than
+an address to be dialed.
+The
+.B s
+option causes
+.I srv
+to sleep for the specified number of seconds
+after establishing the connection
+before posting and mounting it.
+This is sometimes needed by
+.IR srvssh .
+.PP
+The specified
+.I service
+must serve 9P.  Usually
+.I service
+can be omitted; when calling some
+non-Plan-9 systems, a
+.I service
+such as
+.B u9fs
+must be mentioned explicitly.
+.PP
+The
+.I 9fs
+command does the
+.I srv
+and the
+.I mount
+necessary to make available the files of
+.I system
+on network
+.IR net .
+The files are mounted on
+.IR mountpoint ,
+if given;
+otherwise they are mounted on
+.BI /n/ system\f1.
+If
+.I system
+contains
+.L /
+characters, only the last element of
+.I system
+is used in the
+.B /n
+name.
+.PP
+.I 9fs
+recognizes some special names, such as
+.B dump
+to make the dump file system available on
+.BR /n/dump .
+.I 9fs
+is an
+.IR rc (1)
+script; examine it to see what local conventions apply.
+.PP
+.I Srvssh
+is an
+.IR rc (1)
+command that
+connects to a remote Unix system via 
+.IR ssh (1)
+and starts
+.IR u9fs (4).
+The
+.B -u
+option specifies the path to the
+.B u9fs
+binary on the remote system.
+(By default, an unrooted path of
+.B u9fs
+is used; if the binary is in the path of
+the remote SSH server, you don't need the
+.B -u
+option.)
+For information about the other options,
+see the introductory comment in
+.BR /rc/bin/srvssh .
+The arguments are the same as
+.IR srv .
+.PP
+.I Srvold9p
+is a compatibilty hack to allow Fourth Edition Plan 9 systems
+to connect to older 9P servers.
+It functions as a variant of
+.I srv
+that performs a version translation on the 9P messages on the underlying connection.
+Some of its options are the same as those of
+.IR srv ;
+the special ones are:
+.TF "-x commandxx"
+.PD
+.TP
+.B -d
+Enable debugging.
+.TP
+.B -F
+Insert a special (internal) filter process to the connection to maintain
+message boundaries; usually only needed on TCP connections.
+.TP
+.BI -p\  servicename
+Post the service under
+.IR srv (3)
+as
+.BI /srv/ servicename\f1.
+.TP
+.BI -u\  user
+When connecting to the remote server, log in as
+.IR user .
+Since
+.I srvold9p
+does no authentication, and since new kernels cannot authenticate to
+old services, the likeliest value of
+.I user
+is
+.BR none .
+.TP
+.BI -x\  command
+Run
+.I command
+and use its standard input and output as the 9P service connection.
+If the
+.I command
+string contains blanks, it should be quoted.
+.TP
+.BI -n\  network-addr
+Dial
+.I network-addr
+to establish the connection.
+.TP
+.BI -f\  file
+Use
+.I file
+(typically an existing
+.IR srv (3)
+file) as the connection.
+.PP
+.I Srvold9p
+is run automatically when a
+.IR cpu (1)
+call is received on the service port for the old protocol.
+.SH EXAMPLES
+To see kremvax's and deepthought's files in
+.B /n/kremvax
+and
+.BR /n/deepthought :
+.IP
+.EX
+9fs kremvax
+9fs hhgttg /n/deepthought
+.EE
+.PP
+To mount as user
+.B none
+a connection to an older server kgbsun:
+.IP
+.EX
+srvold9p -u none -m /n/kgbsun -p kgbsun -n il!kgbsun
+.EE
+.PP
+Other windows may then mount the connection directly:
+.IP
+.EX
+mount /srv/kgbsun /n/kgbsun
+.EE
+.PP
+To connect to an instance of the Unix server
+.IR u9fs (4)
+started via
+.IR ssh (1):
+.IP
+.EX
+srvssh unix
+.EE
+.SH FILES
+.TF /srv/*
+.TP
+.B /srv/*
+ports to file systems and servers posted by
+.I srv
+and
+.I 9fs
+.SH SOURCE
+.B /sys/src/cmd/srv.c
+.br
+.B /rc/bin/9fs
+.br
+.B /rc/bin/srvssh
+.br
+.B /sys/src/cmd/srvold9p
+.SH "SEE ALSO"
+.IR bind (1),
+.IR auth (2),
+.IR dial (2),
+.IR srv (3),
+.IR exportfs (4),
+.IR import (4),
+.IR ftpfs (4),
+.IR u9fs (4)
+.SH BUGS
+.I Srv
+does not explicitly report failures of
+.I auth_proxy
+(see
+.IR auth (2));
+.I mount
+(see
+.IR bind (1))
+does.
diff --git a/sys/man/4/tapefs b/sys/man/4/tapefs
new file mode 100755
index 000000000..26f2afa58
--- /dev/null
+++ b/sys/man/4/tapefs
@@ -0,0 +1,109 @@
+.TH TAPEFS 4
+.SH NAME
+32vfs, cpiofs, tapfs, tarfs, tpfs, v6fs, v10fs, zipfs \- mount archival file systems
+.SH SYNOPSIS
+.B fs/32vfs
+[
+.B -b
+.I blocksize
+]
+[
+.B -m
+.I mountpoint
+]
+[
+.B -p
+.I passwd
+]
+[
+.B -g
+.I group
+]
+.I file
+.br
+.B fs/cpiofs
+.br
+.B fs/tapfs
+.br
+.B fs/tarfs
+.br
+.B fs/tpfs
+.br
+.B fs/v6fs
+.br
+.B fs/v10fs
+.br
+.B fs/zipfs
+.br
+.SH DESCRIPTION
+These commands interpret data from traditional tape or file system formats
+stored in
+.IR file ,
+and mount their contents (read-only) into a Plan 9 file system.
+The optional
+.B -p
+and
+.B -g
+flags specify Unix-format password (respectively group) files
+that give the mapping between the numeric user- and group-ID
+numbers on the media and the strings reported by Plan 9 status
+inquiries.
+The
+.B -m
+flag introduces the name at which the new file system should be
+attached; the default is
+.BR /n/tapefs .
+.PP
+.I 32vfs
+interprets raw disk images of 32V systems, which are ca. 1978 research Unix systems for
+the VAX (512 byte block size, the default), and also pre-FFS Berkeley VAX systems (1KB block size).
+.PP
+.I Cpiofs
+interprets
+.B cpio
+tape images (constructed with
+.BI cpio 's
+.B c
+flag).
+.PP
+.I Tarfs
+interprets
+.I tar
+tape images.
+.PP
+.I Tpfs
+interprets
+.I tp
+tapes from the Fifth through Seventh Edition research Unix systems.
+.PP
+.I Tapfs
+interprets
+.I tap
+tapes from the pre-Fifth Edition era.
+.PP
+.I V6fs
+interprets disk images from the
+Fifth and Sixth edition research Unix systems (512B block size).
+.PP
+.I V10fs
+interprets disk images from the
+Tenth Edition research Unix systems (4KB block size).
+.PP
+.I Zipfs
+interprets zip archives (see
+.IR gzip (1)).
+.SH SOURCE
+.PP
+These commands are constructed in a highly stereotyped
+way using the files
+.I fs.c
+and
+.I util.c
+in
+.BR /sys/src/cmd/tapefs ,
+which in
+turn derive substantially from
+.IR ramfs (4).
+.SH "SEE ALSO
+.IR intro (5),
+.IR ramfs (4).
diff --git a/sys/man/4/telco b/sys/man/4/telco
new file mode 100755
index 000000000..027541eec
--- /dev/null
+++ b/sys/man/4/telco
@@ -0,0 +1,237 @@
+.TH TELCO 4
+.SH NAME
+telco, faxreceive, faxsend, fax, telcofax, telcodata \- telephone dialer network
+.SH SYNOPSIS
+.B telco
+[
+.B -p
+] [
+.B -i
+.I source-id
+] [
+.B -v
+]
+.I dialer-devs
+.PP
+.B aux/faxsend
+.I address
+.I page1
+\&...
+.PP
+.B aux/faxreceive
+[
+.B -s
+.I spool-dir
+] [
+.B -v
+]
+.PP
+.B fax
+[
+.B -v
+]
+.I telno
+.I recipient
+[
+.I files
+]
+.PP
+.B service/telcofax
+.PP
+.B service/telcodata
+.SH DESCRIPTION
+.I Telco
+is a file server that provides a network interface to
+Hayes telephone dialers.
+The interface is the same as that provided by
+.IR ip (3)
+and can be used by any program that makes network connections using
+.IR dial (2).
+The network addresses used by
+.I telco
+are telephone
+numbers.
+.PP
+The options are
+.TP
+.B -p
+use pulse dialing
+.TP 
+.B -v
+verbose: write to the log file all communications with
+the dialer.
+.TP 
+.B -i
+specify a
+.I source-id
+to be used during FAX transfers
+.PP
+Some control of outgoing calls can be encoded
+in the address.
+Normally, addresses are of the form
+.IB telco ! number\f1,
+where 
+.I number
+is a decimal telephone number.
+However, commas in the telephone number can be used to insert
+pauses in the dialing process.
+Dialing options can be added to the end of the address, separated
+by
+.BR ! 's.
+The dialing options are
+.TF baudrate
+.TP
+.B compress
+turn on compression (default off)
+.TP
+.I baudrate
+a decimal number representing the highest baud
+rate with which to make the call
+.TP
+.B fax
+to make a Class 2 facsimile call (used by programs such as
+.IR faxsend )
+.PD
+.PP
+.I Telco
+also answers incoming calls.
+Upon receiving a facsimile call,
+.I telco
+starts the script
+.BR /rc/bin/service/telcofax .
+For data calls it starts
+.BR /rc/bin/service/telcodata .
+Each is started with the network connection as both standard
+input and standard output and with two arguments,
+the file name of the network connection, e.g.,
+.BR /net/telco/0/data ,
+and the type of modem.
+Currently, the only modem types supported are:
+.TF ATT14400
+.TP
+.B MT1432
+Multitech's 14400 baud modem
+.TP
+.B MT2834
+Multitech's 28800 baud modem
+.TP
+.B ATT14400
+the 14400 baud modem in Safaris
+.TP
+.B VOCAL
+the 14400 baud Vocal modem
+.PD
+.PP
+All other modems are assumed to be compatible with the standard
+Hayes command subset.
+.PP
+.I Faxreceive
+is normally started by
+.BR /rc/bin/service/telcofax .
+It reads and spools a CCITT Group 3 (G3) encoded FAX, and then starts the
+script
+.BR /sys/lib/fax/receiverc ,
+passing it four arguments: the spool file name,
+.B Y
+(for success) or
+.BR N ,
+the number of pages, and the id string passed by the caller.
+This script sends by
+.IR mail (1)
+notification to a list of recipients kept in the file
+.BR /mail/faxqueue/faxrecipients ;
+the script and the list
+should be edited to match local needs.
+.I Faxreceive's
+options are:
+.TP
+.B -s
+specify a different spool directory; the default is
+.BR /mail/faxqueue .
+.TP
+.B -v
+verbose: write to the log file all communications with
+the modem.
+.PP
+.I Faxsend
+transmits a FAX to
+.IR address .
+.I Page1
+and all arguments that follow
+are names of files containing G3 encoded
+FAX images, one per page.
+.PP
+.I Fax
+is a shell script that converts to G3 format
+PostScript, G3, text, or other files acceptable to
+.IR lp (1)
+and queues the result
+to be transmitted to a FAX machine.
+A standard cover sheet, derived from
+.BR /sys/lib/fax/h.ps ,
+is sent before the message.
+.I Telno
+is the destination telephone number.
+.I Recipient
+is the name of the recipient to be placed
+on the cover sheet.
+If no
+.I files
+are specified, standard input is converted and sent.
+The
+.B -v
+option invokes
+.IR page (1)
+on the generated G3 files
+instead of transmitting them via FAX machine.
+.SH EXAMPLE
+Start the dialer on a PC, then use
+.I con
+to phone out.
+.IP
+.EX
+telco /dev/eia1
+con -l telco!18005551212
+.EE
+.PP
+The connection will be made at the highest
+negotiable baud rate.  To use the
+best negotiable compression scheme as well:
+.IP
+.EX
+con -l telco!18005551212!compress
+.EE
+.SH FILES
+.B /mail/faxqueue/*
+.br
+.B /rc/bin/service/telcodata
+.br
+.B /rc/bin/service/telcofax
+.br
+.B /sys/log/telco
+.br
+.B /sys/lib/fax/receiverc
+.br
+.B /mail/faxqueue/faxrecipients
+.br
+.B /sys/lib/fax/h.ps
+.br
+.B /sys/log/fax
+.SH SOURCE
+.B /sys/src/cmd/telco/*
+.br
+.B /sys/src/cmd/fax/*
+.SH "SEE ALSO"
+.IR con (1),
+.IR ip (3)
+.SH BUGS
+.PP
+These programs require the Class 2 facsimile interface.  This means that
+.I faxsend
+and
+.I faxreceive
+will not work on most portable computers since they have Class 1
+interfaces.
+.PP
+The modem specific information is currently built into the source.
+This should be in a user modifiable file.
diff --git a/sys/man/4/u9fs b/sys/man/4/u9fs
new file mode 100755
index 000000000..f253d8fee
--- /dev/null
+++ b/sys/man/4/u9fs
@@ -0,0 +1,289 @@
+.TH U9FS 4
+.SH NAME
+u9fs \- serve 9P from Unix
+.SH SYNOPSIS
+.B u9fs
+[
+.B -Dnz
+]
+[
+.B -a
+.I authtype
+]
+[
+.B -A
+.I autharg
+]
+[
+.B -l
+.I logfile
+]
+[
+.B -m
+.I msize
+]
+[
+.B -u
+.I onlyuser
+]
+.I fsroot
+.SH DESCRIPTION
+.I U9fs
+is
+.I not
+a Plan 9 program.  Instead it is a program that
+serves Unix files to Plan 9 machines using the 9P protocol
+(see
+.IR intro (5)).
+It is typically invoked on a
+Unix machine by
+.B inetd
+with its standard input and output connected to a
+network connection, typically TCP on an Ethernet.
+It typically runs as user
+.B root
+and multiplexes access to multiple Plan 9 clients over the single wire.
+It assumes Plan 9 uids match Unix login names,
+and changes to the corresponding Unix effective uid when processing requests.
+Characters in file and directory names unacceptable to Plan 9 are translated
+into a three-character sequence:
+.L \e
+followed by two hexadecimal digits.
+.I U9fs
+serves both 9P1 (the 9P protocol as used by
+the second and third editions of Plan 9) and 9P2000.
+.PP
+The options are:
+.TF "\fL-A \fIautharg"
+.PD
+.TP
+.B -D
+Write very chatty debugging output to the log file (see
+.B -l
+option below).
+.TP
+.B -n
+Signals that
+.I u9fs
+is
+.I not
+being invoked with a network connection
+on standard input and output, and thus should
+not try to determine the remote address of the connection.
+This is useful when
+.I u9fs
+is not invoked from
+.I inetd
+(see examples below).
+.TP
+.B -z
+Truncate the log file on startup.  This is useful mainly when debugging
+with
+.BR -D .
+.TP
+.BI -a " authtype
+Sets the authentication method to be used.
+.I Authtype
+should be
+.BR rhosts ,
+.BR none ,
+or
+.BR p9any .
+The default is
+.BR rhosts ,
+which uses the
+.I ruserok
+library call to authenticate users by entries in
+.B /etc/hosts.equiv
+or
+.BR $HOME/.rhosts .
+This default is discouraged for all but the most controlled networks.
+Specifying
+.B none
+turns off authentication altogether.
+This is useful when
+.I u9fs
+is not invoked from
+.I inetd
+(see examples below, or
+.I srvssh
+in
+.IR srv (4)).
+Specifying
+.B p9any
+uses the fourth edition Plan 9 authentication mechanisms.
+The file
+.BR /etc/u9fs.key ,
+or
+.I autharg
+if specified
+(see the
+.B -A
+option),
+is consulted for the authentication data
+and should be suitably protected.
+This file must contain exactly three lines:
+.I secret
+(plaintext password),
+.I u9fs-user
+(user id),
+and
+.I plan9-auth.dom
+(authentication domain).
+.RS
+.LP
+Finally,
+.I factotum
+must be taught a key of the form:
+.LP
+.EX
+.B
+key proto=p9sk1 dom=\fIplan9-auth.dom\fP user=\fIu9fs-user\fP !password=\fIsecret\fP
+.EE
+.RE
+.TP
+.BI -A " autharg
+Used to specify an argument to the authentication method.
+See the authentication descriptions above.
+.TP
+.BI -l " logfile
+Specifies the file which should contain debugging output
+and other messages.
+The out-of-the-box compile-time default is
+.BR /tmp/u9fs.log .
+.TP
+.BI -m " msize
+Set
+.I msize
+for 9P2000
+(see
+.IR open (5)).
+.TP
+.BI -u " user
+Treat all attaches as coming from
+.IR user .
+This is useful in some cases when running without
+.IR inetd ;
+see the examples.
+.PP
+If
+.I fsroot
+is specified,
+.I u9fs
+will serve only that tree; othwise, it will serve the entire Unix
+file system.
+.SH EXAMPLES
+.PP
+Plan 9 calls 9P file service
+.B 9fs
+with TCP port number 564.
+Set up this way on a machine called, say,
+.BR kremvax ,
+.I u9fs
+may be connected to the name space of a Plan 9 process by
+.IP
+.EX
+9fs kremvax
+.EE
+.PP
+For more information on this procedure, see
+.IR srv (4)
+and
+.IR bind (1).
+.PP
+By default,
+.I u9fs
+serves the entire file system of the Unix machine.
+It forbids access to devices
+because the program is single-threaded and may block unpredictably.
+Using the
+.B attach
+specifier
+.B device
+connects to a file system identical to the usual system except
+it only permits device access (and may block unpredictably):
+.IP
+.EX
+srv tcp!kremvax!9fs
+mount -c /srv/tcp!kremvax!9fs /n/kremvax device
+.EE
+.PP
+(The
+.B 9fs
+command
+does not accept an attach specifier.)
+Even so,
+device access may produce unpredictable
+results if the block size of the device is greater than 8192,
+the maximum data size of a 9P message.
+.PP
+The source to
+.I u9fs
+is in the Plan 9 directory
+.BR /sys/src/cmd/unix/u9fs .
+To install
+.I u9fs
+on a Unix system with an ANSI C compiler, copy the source to a directory on that system
+and run
+.BR make .
+Then install the binary in
+.BR /usr/etc/u9fs .
+Add this line to
+.BR inetd.conf :
+.IP
+.EX
+9fs     stream  tcp     nowait  root   /usr/etc/u9fs   u9fs
+.EE
+.PP
+and this to
+.BR services :
+.IP
+.EX
+9fs     564/tcp       9fs  # Plan 9 fs
+.EE
+.LP
+Due to a bug in their
+IP software, some systems will not accept the service name
+.BR 9fs ,
+thinking it
+a service number because of the initial digit.
+If so, run the service as
+.B u9fs
+or
+.BR 564 .
+.PP
+On systems where listeners cannot be started,
+.IR execnet (4)
+is useful for running
+.I u9fs
+via other network mechanisms; the script
+.I srvssh
+in
+.IR srv (4)
+provides this for the
+.I ssh
+protocol.
+.SH SOURCE
+.B /sys/src/cmd/unix/u9fs
+.SH DIAGNOSTICS
+Problems are reported to the
+log file specified with the
+.B -l
+option (default
+.BR /tmp/u9fs.log ).
+The
+.B -D
+flag enables chatty debugging.
+.SH SEE ALSO
+.IR bind (1),
+.IR execnet (4),
+.IR srv (4),
+.IR ip (3),
+.IR nfsserver (8)
+.SH BUGS
+The implementation of devices is unsatisfactory.
+.LP
+Semantics like remove-on-close or the
+atomicity of
+.B wstat
+are hard to provide exactly.
diff --git a/sys/man/4/upasfs b/sys/man/4/upasfs
new file mode 100755
index 000000000..d6a65041f
--- /dev/null
+++ b/sys/man/4/upasfs
@@ -0,0 +1,351 @@
+.TH UPASFS 4
+.SH NAME
+upasfs, startupasfs \- mail file server
+.SH SYNOPSIS
+.B upas/fs
+[
+.B -f
+.I mailbox
+] [
+.B -bnps
+] [
+.B -m
+.I mntpoint
+]
+.PP
+.B startupasfs
+.SH DESCRIPTION
+.I Fs
+is a user level file system that reads mailboxes and presents them as a file
+system.
+A user normally starts
+.I fs
+in his/her profile after starting
+.IR plumber (4)
+and before starting
+a window system, such as
+.IR rio (1)
+or
+.IR acme (1).
+The file system is used by
+.I nedmail
+and
+.IR acme (1)'s
+mail reader to parse messages.
+.I Fs
+also generates plumbing messages used by
+.IR biff
+and
+.IR faces (1)
+to provide mail announcements.
+.PP
+.I Startupasfs
+is a shell script suitable for use in one's profile.
+It runs
+.B "fs -s"
+for the invoking user if none is already running,
+and always mounts the user's posted
+.I fs
+on
+.BR /mail/fs .
+.PP
+The mailbox itself becomes a directory under
+.BR /mail/fs .
+Each message in the mailbox becomes a numbered directory in the
+mailbox directory, and each attachment becomes a numbered directory
+in the message directory.  Since an attachment may itself be a mail message,
+this structure can recurse ad nauseam.
+.PP
+Each message and attachment directory contains the files:
+.TP 1.4i
+.B body
+.PD 0
+the message minus the RFC822 style headers
+.TP
+.B cc
+the address(es) from the CC: header
+.TP
+.B date
+the date in the message, or if none, the time of delivery
+.TP
+.B digest
+an SHA1 digest of the message contents
+.TP
+.B disposition
+.B inline
+or
+.B file
+.TP
+.B filename
+a name to use to file an attachment
+.TP
+.B from
+the from address in the From: header, or if none,
+the address on the envelope.
+.TP
+.B header
+the RFC822 headers
+.TP
+.B info
+described below, essentially a summary of the header info
+.TP
+.B inreplyto
+contents of the
+.B in-reply-to:
+header
+.TP
+.B mimeheader
+the mime headers
+.TP
+.B raw
+the undecoded MIME message
+.TP
+.B rawbody
+the undecoded message body
+.TP
+.B rawheader
+the undecoded message header
+.TP
+.B replyto
+the address to send any replies to.
+.TP
+.B subject
+the contents of the subject line
+.TP
+.B to
+the address(es) from the To: line.
+.TP
+.B type
+the MIME content type
+.TP
+.B unixheader
+the envelope header from the mailbox
+.PD
+.PP
+The
+.B info
+file contains the following information, one item per line.  Lists
+of addresses are single-space separated.
+.LP
+.2C
+.PD 0
+.LP
+.TP 2i
+.I "sender address
+.TP
+.I "recipient addresses
+.TP
+.I "cc addresses
+.TP
+.I "reply address
+.TP
+.I "envelope date
+.TP
+.I "subject
+.TP
+.I "MIME content type
+.TP
+.I "MIME disposition
+.TP
+.I filename
+.TP
+.I "SHA1 digest
+.TP
+.I "bcc addresses
+.TP
+.I "in-reply-to: contents
+.TP
+.I "RFC822 date
+.TP
+.I "message senders
+.TP
+.I "message id
+.TP
+.I "number of lines in body
+.LP
+.1C
+.PD
+.PP
+Deleting message directories causes the message to be removed from
+the mailbox.
+.PP
+The mailbox is reread and the structure updated
+whenever the mailbox changes.  Message directories are
+not renumbered.
+.PP
+The file
+.B /mail/fs/ctl
+is used to direct
+.I fs
+to open/close new mailboxes or to delete groups of messages atomically.
+The messages that can be written to this file are:
+.TF "delete\fI mboxname number ...\fP
+.TP
+.BI open " path mboxname"
+opens a new mailbox.
+.I path
+is the file to open, and
+.I mboxname
+is the name that appears under
+.BR /mail/fs .
+.TP
+.BI close " mboxname"
+close
+.IR mboxname .
+The close takes affect only after all files open under
+.BI /mail/fs/ mboxname
+have been closed.
+.TP
+.BI delete " mboxname number ..."
+Delete the messages with the given numbers from
+.IR mboxname.
+.PD
+.PP
+The options are:
+.TF "-f\fI file
+.TP
+.BI -f file
+use
+.I file
+as the mailbox instead of the default,
+.BI /mail/box/ username /mbox.
+.PD 0
+.TP
+.B -b
+stands for biffing.  Each time new mail
+is received, a message is printed to standard
+output containing the sender address, subject,
+and number of bytes.  It is intended for
+people telnetting in who want mail announcements.
+.TP
+.B -n
+Don't open a mailbox initially.  Overridden by -f.
+.TP
+.B -p
+turn off plumbing.  Unless this is specified,
+.I fs
+sends a message to the plumb port,
+.BR seemail ,
+from source
+.B mailfs
+for each message received or deleted.
+The message contains the attributes
+.BI sender= "<contents of " from " file>,"
+.BR filetype=mail ,
+.BR "mailtype=deleted\fI or \fPnew" ,
+and
+.BI length= "<message length in bytes>."
+The contents of the message is the full path
+name of the directory representing the message.
+.TP
+.B -s
+causes
+.I fs
+to post itself in
+.B /srv
+with a name of the form
+.BI /srv/upasfs. user.
+.TP
+.B -m
+specifies a mount point other than
+.BR /mail/fs .
+.PD
+.PP
+.I Fs
+will exit once all references to its directory
+have disappeared.
+.PP
+.I Fs
+interprets mailbox file names of the form
+.BI / proto / host / user
+to mean access an account on
+.I host
+using the given protocol.
+Authentication is delegated to
+.IR factotum (4).
+The final
+.BI / user
+may be omitted, in which case
+the user name is gleaned from the key held by
+.IR factotum .
+The following protocols are supported:
+.PP
+.TF apoptls
+.TP
+.B pop
+cleartext POP with password authentication
+.TP
+.B apop
+cleartext POP with challenge-response (APOP) authentication
+.TP
+.B pops
+.TP
+.B poptls
+TLS-encrypted POP with password authentication
+.TP
+.B apops
+.TP
+.B apoptls
+TLS-encrypted POP with challenge-response (APOP) authentication
+.TP
+.B imap
+cleartext IMAP
+.TP
+.B imaps
+TLS-encrypted IMAP
+.PD
+.PP
+The two IMAP protocols allow an optional fourth field
+specifying a mailbox name, for example
+.BR /imap/server/user/stored .
+.PP
+.B Poptls
+and
+.B apoptls
+connect to port 110 in plaintext and start TLS using the POP
+STLS command.
+.B Pops
+and
+.B apops
+connect to port 995 and start TLS before initiating the POP conversation.
+.B Imaps
+connects to port 993 and starts TLS before initiating the IMAP conversation.
+There should probably be an
+.B imaptls
+protocol as well.
+.RB ( Imaptls
+would connect to port 143 in plaintext and start TLS using the IMAP
+STARTTLS command.
+(That's the nice thing about standards\(emthere's so many to choose from.))
+.SH FILES
+.TF /mail/box/*/dead.letter
+.TP
+.B /mail/box/*
+mail directories
+.TP
+.B /mail/box/*/mbox
+mailbox files
+.TP
+.B /mail/box/*/L.reading
+mutual exclusion lock for multiple mbox readers
+.TP
+.B /mail/box/*/L.mbox
+mutual exclusion lock for altering mbox
+.br
+.ne 3
+.SH SOURCE
+.B /sys/src/cmd/upas/fs
+.br
+.B /rc/bin/startupasfs
+.SH "SEE ALSO"
+.IR aliasmail (8),
+.IR faces (1),
+.IR filter (1),
+.IR mail (1),
+.IR marshal (1),
+.IR mlmgr (1),
+.IR nedmail (1),
+.IR qer (8),
+.IR rewrite (6),
+.IR send (8),
+.IR upasfs (4)
diff --git a/sys/man/4/usb b/sys/man/4/usb
new file mode 100755
index 000000000..5df684c9e
--- /dev/null
+++ b/sys/man/4/usb
@@ -0,0 +1,514 @@
+.TH USB 4
+.SH NAME
+audio,
+ccid,
+disk,
+ether,
+kb,
+print,
+probe,
+serial,
+usbeject,
+usbfat:
+\- Universal Serial Bus device drivers
+.SH SYNOPSIS
+.B usb/kb
+[
+.B -dkm
+] [
+.B -a
+.I accel
+] [
+.I dev ...
+]
+.PP
+.B usb/disk
+[
+.B -Dd
+] [
+.B -m
+.I mnt
+] [
+.B -s
+.I srv
+] [
+.I dev ...
+]
+.PP
+.B usbfat:
+[
+.I disk ...
+]
+.PP
+.B usbeject
+[
+.I disk ...
+]
+.PP
+.B usb/audio
+[
+.B -dpV
+] [
+.B -m
+.I mnt
+] [
+.B -s
+.I srv
+] [
+.B -v
+.I vol
+] [
+.I dev
+]
+.PP
+.B usb/ether
+[
+.B -Dd
+] [
+.B -m
+.I mnt
+] [
+.B -s
+.I srv
+] [
+.I dev ...
+]
+.PP
+.B usb/serial
+[
+.B -Dd
+] [
+.B -m
+.I mnt
+] [
+.B -s
+.I srv
+] [
+.I dev ...
+]
+.PP
+.B usb/print
+[
+.B -d
+] [
+.I dev ...
+]
+.PP
+.B usb/ccid
+[
+.B -d
+]
+.ig
+.PP
+.B usb/ibuddy
+[
+.B -Dd
+] [
+.B -m
+.I mnt
+] [
+.B -s
+.I srv
+] [
+.I dev ...
+]
+..
+.B usb/probe
+.SH DESCRIPTION
+These programs drive USB devices of specific classes via
+.IR usb (3).
+Usually they are started by
+.IR usbd (4)
+upon attachment of the device to the bus.
+Less often, users start them manually, depending on
+.IR usbd (4)'s
+configuration.
+Usually,
+.I kb
+and
+.I disk
+are started by
+.I usbd
+and other programs are started by hand.
+.PP
+Without arguments, the drivers handle all the devices (of
+the appropriate USB class) found on the bus.
+To make a driver handle only certain devices, supply as arguments
+the paths for the directories of the devices
+(actually of their zero endpoints).
+.PP
+Drivers that provide file systems accept options
+.B -s
+and
+.B -m
+to instruct them to post a 9P connection at
+.IR srv (3)
+with the given name and/or to mount themselves at
+.IR mnt .
+When embedded into
+.IR usbd
+these options may not be used.
+In this case,
+the file tree supplied by the device driver is
+available through the file system provided by
+.IR usbd ,
+usually mounted at
+.B /dev
+and reachable through the 9P connection posted at
+.BR /srv/usb .
+.PP
+Options
+.B -d
+and
+.B -D
+present on most drivers trigger debug diagnostics and
+file system debugging diagnostics.
+Repeating any one of these may increase verbosity.
+.PP
+To help locate devices of interest,
+.I probe
+lists all the USB devices available,
+including those with no driver started.
+.SS Keyboards and mice
+.I Kb
+supports USB keyboards and mice either as separate USB devices
+or as a single combined USB device.
+Scan codes from the keyboard are sent to
+.B /dev/kbin
+to let the kernel process them.
+Mouse events are sent to
+.B /dev/mousein
+in the same way.
+.PP
+The following options are understood:
+.TF -k
+.TP
+.B \-a
+Accelerate the mouse to level
+.I n
+(similar to the kernel mouse driver acceleration).
+.TP
+.B \-k
+Serve just the keyboard (and not the mouse).
+.TP
+.B \-m
+Serve just the mouse (and not the keyboard).
+.SS Disks
+.I Disk
+configures and manages USB mass storage devices. It
+provides a file system (usually seen at
+.BR /dev )
+that includes one directory per storage device, named
+.BI sdU N . M
+in correspondence with the usb device number and the storage
+unit number (or LUN).
+For example, LUN number 2 on
+.B /dev/usb/ep3.0
+can be accessed through
+.BR /dev/sdU3.2 .
+.PP
+The storage device directory contains the usual files
+served by
+.IR sd (3):
+.BR data ,
+.BR raw ,
+and
+.BR ctl .
+.PP
+The
+.B ctl
+file supplies the device
+geometry when read.
+.PP
+The script
+.B usbfat:
+mounts the FAT file systems in the DOS partitions of the named
+.IR disk s;
+if none, it mounts those file systems found at
+.BR /dev/sdU*.*/data .
+When more than one partition is found, a suffix is appended to
+the disk name to identify the partition number.
+The script
+.B usbeject
+undoes the effect. If no argument is given, it unmounts all USB
+disks. An argument
+.BI sdU N
+unmounts all partitions from disk with USB target
+.IR N .
+.ig
+An argument
+.BI sdU N . M
+or
+.BI sdU N . M . P
+.\" TODO: fill in missing words
+..
+.SS Printers
+.I Print
+provides a single file can be written to print on a USB printer.
+Options are similar to those of
+.IR disk .
+The file is also bound at
+.B /dev/lp
+as is customary.
+.SS Ethernet adapters
+.I Ether
+provides a file interface similar to that of
+.IR ether (3)
+for each USB Ethernet adapter found.
+The name of an Ethernet device is
+.BI etherU N
+where
+.I N
+is the device name.
+When started manually, the file interface is mounted at
+.B /net
+as is customary.
+.
+.SS Serial and JTAG ports
+.I Serial
+provides a file system (usually mounted at
+.BR /dev )
+that includes one directory per USB serial port, named
+.BI eiaU N
+or
+.BI eiaU N . M.
+In this directory there are two files,
+.BR eiaU ,
+similar to
+.BI eia N
+in
+.IR uart (3),
+and
+.BR eiaUctl ,
+which admits writes in the same format as
+.BI eia N ctl
+in
+.IR uart (3).
+Reading from
+.B eiaUctl
+gives the serial port's settings in the same format as
+.BI eia N status
+in
+.IR uart (3).
+Options are similar to those of
+.IR disk .
+.PP
+JTAG ports are similar
+but the files are named
+.B jtag
+and
+.BR jtagctl .
+.
+.SS Audio devices
+.I Usbaudio
+configures and manages a USB audio device.
+It implements a file system,
+normally mounted on
+.BI /dev ,
+but this can be changed with
+.BR \-m ,
+containing files
+.BR volume ,
+.BR audioctl ,
+.BR audio ,
+and
+.BR audioin .
+The names
+.B volume
+and
+.B audio
+maintain backward compatibility with the Soundblaster driver.
+.PP
+The
+.B \-V
+option (verbose)
+causes
+.I audio
+to print information about the device on startup.
+The
+.B \-s
+option specifies a name for a file descriptor to be posted in
+.BR /srv .
+The
+.B \-v
+options sets initial
+.IR volume .
+.PP
+Reading
+.B volume
+or
+.B audioctl
+yields the device's settings.
+The data format of
+.B volume
+is compatible with the Soundblaster and produces output in this
+format:
+.IP
+.EX
+audio out 65
+treb out 0
+bass out 0
+speed out 44100
+.EE
+.PP
+This file can be written using the same syntax.
+The keyword
+.L out
+may be omitted.
+Settings are given as percentages of the range,
+except for speed which is in Hz.
+.PP
+The file
+.B audioctl
+provides more information, using up to 6 columns of 12 characters each.
+From left to right, the fields are:
+.IR "control name" ,
+.I in
+or
+.IR out ,
+.IR "current value" ,
+.IR "minimum value" ,
+.IR maximum ,
+and
+.IR resolution .
+There are 3, 5, or 6 columns present.
+Maxima and resolution are omitted when they are not available or not applicable.
+The resolution for
+.I speed
+is reported as 1 (one) if the sampling frequency is continuously variable.
+It is absent if it is settable at a fixed number of discrete values only.
+.PP
+When all values from
+.B audioctl
+have been read, a zero-length buffer is returned
+(the usual end-of-file indication).
+A new
+.I read
+will then block until one of the settings changes,
+then report its new value.
+.PP
+The file
+.B audioctl
+can be written like
+.BR volume .
+.PP
+Audio data is written to
+.B audio
+and read from
+.BR audioin .
+The data format is little-endian,
+samples ordered primarily by time and
+secondarily by channel.
+Samples occupy the minimum integral number of bytes.
+Read and write operations of arbitrary size are allowed.
+.
+.SS Ccid
+.I Ccid
+discovers and configures SIM or SAM cards using the CCID standard.
+It provides a file system (usually mounted at
+.BR /dev )
+that includes three files,
+.BI ctl ,
+.B raw
+and
+.BI rpc .
+Reading from
+.B ctl
+a description of the smartcard reader capabilities is printed.
+.B raw
+is just intended for debugging.
+Reads and writes to the
+raw file send and receive raw CCID packets.
+Smart cards identify themselves by giving out an ATR,
+an array of characters describing the card uniquely.
+Users of the driver write the ATR to the
+.B rpc
+file and are blocked until a card with that ATR is seen.
+From then on they can do ICC RPCs using whatever
+language the smart card speaks. A small write cancels
+an outstanding RPC.
+.PP
+The driver takes care of powering the card adequately, based
+on its ATR, and tunnelling the RPCs through the USB device.
+Only slot 0 is supported.
+.PP
+When the smartcard disappears,
+all reads and write fail until the file is reopened and
+a new ATR is written to it.
+.
+.ig
+.SS Ibuddy
+.PP
+Ibuddy supports a USB I-buddy toy, a little winged-demon.
+The driver provides one directory per attached toy with a single
+.BR ctl
+file to control the device.
+Directories are named
+.BR ibuddyN ,
+being
+.I N
+the corresponding usb device number.
+When read, the
+.BR ctl
+file provides the state of the device in this form:
+.IP
+.EX
+hips right|left
+wings open|close
+red on|off
+green on|off
+blue on|off
+heart on|off
+.EE
+.PP
+Each line describes the status of one feature.
+.IR  Red ,
+.IR  blue ,
+and
+.IR  green
+are the different leds in the head of
+the toy.
+.IR  Heart
+represents the red led in the chest of
+the toy.
+.IR  Wings
+represents the status of the wings, which
+can be closed or open.
+.IR  Hips
+represents the orientation
+of the toy (left or right, from the figure's point of view).
+.PP
+Lines can be written to the
+.BR ctl
+file to command the device.
+Multiple lines (six at most) can be written
+at once, with one action per line.
+..
+.SH SOURCE
+.B /sys/src/cmd/usb
+.SH "SEE ALSO"
+.IR kbin (3),
+.IR mouse (3),
+.IR sd (3),
+.IR uart (3),
+.IR usb (3),
+.IR usbd (4),
+.IR partfs (8)
+.SH BUGS
+The various device drivers are generic USB drivers and
+may work only for certain devices on each class.
+.PP
+USB ATA storage devices are not supported.
+.PP
+The Ethernet device works only for certain ASIX-based cards and for CDC devices.
+Both the Ethernet and printer drivers have not
+been tested and it is likely they will fail.
+.PP
+The serial driver works only for the Prolific chip and Ftdi,
+and control of the
+.B dcd
+and
+.B dsr
+signals and some of the extra features are unimplemented.
+For Ftdi, only the Sheevaplug and Guruplug have been tried.
+There is support for the EHCI debug port, but it loses bytes.
diff --git a/sys/man/4/usbd b/sys/man/4/usbd
new file mode 100755
index 000000000..c0d3ca6cd
--- /dev/null
+++ b/sys/man/4/usbd
@@ -0,0 +1,245 @@
+.TH USBD 4
+.SH NAME
+usbd \- Universal Serial Bus daemon
+.SH SYNOPSIS
+.B usbd
+[
+.B -Dd
+]
+[
+.B -s
+.I srv
+]
+[
+.B -m
+.I mnt
+]
+[
+.I hub...
+]
+.SH DESCRIPTION
+.I Usbd
+complements
+.IR usb (3)
+to provide USB I/O for device drivers.
+It enumerates the bus, polling
+hub ports to detect device attachments and detachments, performs
+initial configuration of setup endpoints, and writes extra information into
+.IR usb (3)
+endpoint control files, to ease device location.
+.PP
+By default,
+.I usbd
+opens all setup endpoints found at
+.B #u/usb
+(which correspond to built-in hubs initialized by the kernel during boot).
+Paths to directories representing setup endpoints for hubs can be given
+as arguments to restrict
+.I usbd
+operation to such hubs.
+.PP
+When a device is attached,
+depending upon a configuration file compiled into
+.I usbd ,
+the appropriate device driver may be started without
+user intervention.
+This mechanism can be used to statically link some USB device drivers into
+.I usbd
+itself.
+Initial configuration for setup endpoints is performed independently
+of this configuration.
+.PP
+.I Usbd
+provides a file interface used to change debugging flags, and also used by
+USB device drivers statically linked into
+.IR usbd .
+By default, the file system is mounted (after) at
+.B /dev
+and a 9P connection is posted at
+.BR /srv/usb .
+.PP
+Besides files provided by device drivers, the file
+.B usbdctl
+is always present in the file interface.
+It accepts these control requests:
+.TF "fsdebug\fI n
+.TP
+.BI debug " n"
+Sets the debugging level to
+.IR n .
+.TP
+.BI fsdebug " n"
+Sets the file system debugging level to
+.IR n .
+.TP
+.B dump
+Prints the list of devices and file systems known by
+.IR usbd .
+.PD
+.PP
+.I Usbd
+recognizes the following options:
+.TF "-m\fI mnt
+.TP
+.B -d
+Print debugging diagnostics.
+Repeating the option increases verbosity.
+.TP
+.B -D
+Print debugging diagnostics for the file system interface.
+.TP
+.BI -m " mnt"
+Mount the served file system at
+.IR mnt .
+.TP
+.BI -s " srv"
+Post a 9P connection at
+.BI #s/ srv.
+.PD
+.SS Configuration
+.PP
+.I Usbd
+can be configured to start drivers for devices matching one or more CSPs
+(hex representation of USB class, subclass and protocol), class,
+subclass, protocol, vendor id, or device id.
+When a new device is attached,
+.I usbd
+scans the configuration and, if an entry matches the device descriptor, starts
+the driver.
+If no driver is configured, the setup endpoint for the device is left
+configured to let the user start the driver by hand.
+.PP
+Configuration is via compilation
+because one of the options is to embed (link) the driver into the
+.I usbd
+binary.
+If the driver is embedded,
+.I usbd
+creates a process for it and calls its main entry point.
+Otherwise,
+.I usbd
+tries to locate the driver binary in
+.B /bin/usb
+and creates a process to execute it.
+.PP
+The configuration file,
+.BR usbdb ,
+has two sections:
+.B embed
+and
+.BR auto .
+Each section includes lines to configure particular drivers.
+A driver may have more than one line if necessary.
+Each line includes the name of the
+driver (the base name of the binary) and one or more attributes of the form
+.IP
+.IR name = value
+.PP
+The following attributes exist:
+.TF subclass
+.TP
+.B class
+.I Value
+may be the name of the class
+or a number identifying the device class (using C syntax).
+The following class names are known:
+.BR audio ,
+.BR comms ,
+.BR hid ,
+.BR printer ,
+.BR storage ,
+.BR hub ,
+and
+.BR data .
+.TP
+.B subclass
+.I Value
+is the number of the device subclass.
+.TP
+.B proto
+.I Value
+is the number of the device protocol.
+.TP
+.B csp
+.I Value
+is the hexadecimal number describing the CSP for the device.
+.TP
+.B vid
+.I Value
+is the vendor id.
+.TP
+.B did
+.I Value
+is the device id.
+.TP
+.B args
+This must be the last field.
+The value is the rest of the line,
+and is supplied as arguments to the driver process.
+.PD
+.LP
+Several environment variables can be used to alter the behaviour of
+.IR usbd ,
+for example, for use in
+.IR plan9.ini (8).
+.B usbdebug
+sets a debug level (zero for no diagnostics and positive
+values for increasing verbosity).
+.B kbargs
+overrides the keyboard arguments as specified by the configuration file.
+.B diskargs
+overrides the disk arguments in the same way.
+.SH EXAMPLE
+This configuration file links
+.B usb/kb
+into
+.I usbd
+when it is compiled.
+It arranges for the driver's entry point,
+.B kbmain
+in this case,
+to be called for any device with CSPs matching either
+.B 0x010103
+or
+.BR 0x020103 .
+Option
+.B -d
+will be supplied as command line arguments for
+.BR kbmain .
+This configuration also arranges for
+.B /bin/usb/disk
+to start (with no arguments) whenever a device of class
+.B storage
+is attached.
+.IP
+.EX
+embed
+	kb	csp=0x010103 csp=0x020103	args=-d
+auto
+	disk	class=storage	args=
+.EE
+.SH FILES
+.TF /srv/usb
+.TP
+.B /srv/usb
+9P connection to the driver file system.
+.TP
+.B /dev
+mount point for the driver file system.
+.TP
+.B /sys/src/cmd/usb/usbd/usbdb
+Configuration file deciding which devices are included into
+.I usbd
+and which ones are started automatically.
+.SH SOURCE
+.B /sys/src/cmd/usb/usbd
+.SH "SEE ALSO"
+.IR usb (2),
+.IR usb (3),
+.IR usb (4)
+.SH BUGS
+.I Usbd
+is not supposed to be restarted.
+This is arguable.
+.PP
+Not heavily exercised yet.
diff --git a/sys/man/4/vacfs b/sys/man/4/vacfs
new file mode 100755
index 000000000..608fd2a29
--- /dev/null
+++ b/sys/man/4/vacfs
@@ -0,0 +1,90 @@
+.TH VACFS 4
+.SH NAME
+vacfs \- a Venti-based file system
+.SH SYNOPSIS
+.B vacfs
+[
+.B -dips
+]
+[
+.B -c
+.I cachesize
+]
+[
+.B -h
+.I host
+]
+[
+.B -m
+.I mtpt
+]
+[
+.B -S
+.I srvname
+]
+.I vacfile
+.SH DESCRIPTION
+.I Vacfs
+interprets the file system created by
+.IR vac (1)
+so that it can be mounted into a Plan 9 file hierarchy.
+The data for the file system is stored on
+.IR venti (8)
+with a root fingerprint specified in
+.IR vacfile .
+.I Vacfs
+is currently rather limited: access is read-only,
+clients are not authenticated, and groups are assumed to
+contain a single member with the same name.
+These restrictions should eventually be removed.
+.PP
+Options to 
+.I vacfs
+are:
+.TF "-c\fI cachesize"
+.PD
+.TP
+.BI -c " cachesize
+The number of file system blocks to cache in memory. The default is 1000 blocks.
+.TP
+.B -d
+Print debugging information to standard error.
+.TP
+.BI -h " host
+The network address of the Venti server.
+The default is taken from the environment variable
+.BR venti .
+If this variable does not exist, then the default is the
+metaname 
+.BR $venti ,
+which can be configured via
+.IR ndb (6).
+.TP
+.B -i
+Use file descriptors 0 and 1 as the 9P communication channel rather than create a pipe.
+.TP
+.BI -m " mtpt
+The location to mount the file system. The default is
+.BR /n/vac .
+.TP
+.BI -p
+Disables permission checking.
+.TP
+.B -s
+Post the 9P channel in
+.B /srv/vacfs
+rather than
+mounting it on
+.IR mtpt .
+.TP
+.BI -S " srvname
+Post the 9P channel in
+.BI /srv/ srvname
+rather than
+mounting it on
+.IR mtpt .
+.SH SOURCE
+.B /sys/src/cmd/vac
+.SH "SEE ALSO"
+.IR vac (1),
+.IR venti (8)
diff --git a/sys/man/4/webcookies b/sys/man/4/webcookies
new file mode 100755
index 000000000..63842e90f
--- /dev/null
+++ b/sys/man/4/webcookies
@@ -0,0 +1,166 @@
+.TH WEBCOOKIES 4
+.SH NAME
+webcookies \- HTTP cookie manager
+.SH SYNOPSIS
+.B webcookies
+[
+.B -f
+.I cookiefile
+]
+[
+.B -m
+.I mtpt
+]
+[
+.B -s
+.I service
+]
+.SH DESCRIPTION
+.I Webcookies
+manages a set of HTTP cookies, which are
+used to associate HTTP requests with persistent state 
+(such as user profiles) on many web servers.
+.PP
+.I Webcookies
+reads
+.I cookiefile
+(default
+.BR $home/lib/webcookies )
+and mounts itself at 
+.I mtpt
+(default
+.BR /mnt/webcookies ).
+If
+.I service
+is specified, 
+.I cookiefs
+will post a service file descriptor
+in
+.BR /srv/\fIservice .
+.PP
+The cookie file contains one cookie per line;
+each cookie comprises some number of
+.IB attr = value
+pairs.
+Cookie attributes are:
+.TF \fBnetscapestyle=flag
+.TP
+.BI name= name
+The name of the cookie on the remote server.
+.TP
+.BI value= value
+The value associated with that name on the remote server.
+The actual data included when a cookie is sent back
+to the server is
+.IB \fR``\fIname = value\fR''
+(where, confusingly,
+.I name
+and
+.I value
+are the values associated with the
+.B name
+and
+.B value
+attributes.
+.TP
+.BI domain= domain
+The domain within which the cookie can be used.
+If
+.I domain
+is an IP address, the cookie can only be used when
+connecting to a web server at that IP address.
+If
+.I domain
+is a pattern beginning with a dot,
+the cookie can only be used for servers whose name
+has
+.I domain
+as a suffix.
+For example, a cookie with
+.B domain=.bell-labs.com
+may be used on the web sites
+.I www.bell-labs.com
+and
+.IR www.research.bell-labs.com .
+.TP
+.BI path= path
+The cookie can only be used for URLs with a path (the part after
+.BI http:// hostname\fR)
+beginning with
+.IR path .
+.TP
+.BI version= version
+The version of the HTTP cookie specification, specified by the server.
+.TP
+.BI comment= comment
+A comment, specified by the server.
+.TP
+.BI expire= expire
+The cookie expires at time
+.IR expire ,
+which is a decimal number of seconds since the epoch.
+.TP
+.B secure=1
+The cookie may only be used over secure
+.RB ( https )
+connections.
+.TP
+.B explicitdomain=1
+The domain associated with this cookie was set by
+the server (rather than inferred from a URL).
+.TP
+.B explicitpath=1
+The path associated with this cookie was set by the
+server (rather than inferred from a URL).
+.TP
+.B netscapestyle=1
+The server presented the cookie in ``Netscape style,'' which
+does not conform to the cookie standard, RFC2109.
+It is assumed that when presenting the cookie to the server,
+it must be sent back in Netscape style as well.
+.PD
+.PP
+.I Webcookies
+serves a directory containing two files.
+The first,
+.BR cookies ,
+is a textual representation of the cookie file,
+which can be edited to change the set of cookies
+currently held.
+The second,
+.BR http ,
+is intended to be used by HTTP clients
+to access cookies.
+Upon opening
+.BR http ,
+the client must write a full URL to it.
+After writing the URL, reading from the file will yield any
+HTTP
+.B Cookie:
+headers that should be included in the 
+request for this particular URL.
+Once the request has been made, any
+.B Set-Cookie:
+lines in the HTTP response header should
+be written to the file to save them for next time.
+If
+.B cookiefs
+decides not to accept the cookie (as outlined in
+RFC2109, section 4.3.4), no indication is given.
+.PP
+.IR Hget (1)
+uses
+.BR /mnt/webcookies/http ,
+when it exists, to manage cookie state.
+.I Webfs
+does not (yet).
+.SH SOURCE
+.B /sys/src/cmd/webcookies.c
+.SH SEE ALSO
+.IR hget (1)
+.SH BUGS
+It's not clear what the relationship between
+.I cookiefs
+and something like
+.I webfs
+should be.
diff --git a/sys/man/4/webfs b/sys/man/4/webfs
new file mode 100755
index 000000000..5f0d40720
--- /dev/null
+++ b/sys/man/4/webfs
@@ -0,0 +1,308 @@
+.TH WEBFS 4
+.SH NAME
+webfs \- world wide web file system
+.SH SYNOPSIS
+.B webfs
+[
+.B -c
+.I cookiefile
+]
+[
+.B -m
+.I mtpt
+]
+[
+.B -s
+.I service
+]
+.SH DESCRIPTION
+.I Webfs
+presents a file system interface to the parsing and retrieving
+of URLs.
+.I Webfs
+mounts itself at
+.I mtpt
+(default
+.BR /mnt/web ),
+and, if 
+.I service
+is specified, will post a service file descriptor
+in 
+.BR /srv/\fIservice .
+.PP
+.I Webfs
+presents a three-level file system suggestive
+of the network protocol hierarchies
+.IR ip (3)
+and
+.IR ether (3).
+.PP
+The top level contains three files:
+.BR ctl ,
+.BR cookies ,
+and
+.BR clone .
+.PP
+The
+.B ctl
+file is used to maintain parameters global to the instance of
+.IR webfs .
+Reading the 
+.B ctl
+file yields the current values of the parameters.
+Writing strings of the form
+.RB `` attr " " value ''
+sets a particular attribute.
+Attributes are:
+.TP
+.B chatty9p
+The
+.B chatty9p
+flag used by the 9P library, discussed in
+.IR 9p (2).
+.B 0
+is no debugging,
+.B 1
+prints 9P message traces on standard error,
+and values above
+.B 1
+present more debugging, at the whim of the library.
+The default for this and the following debug flags is 
+.BR 0 .
+.TP
+.B fsdebug
+This variable is the level of debugging output about the file system module.
+.TP
+.B cookiedebug
+This variable is the level of debugging output about the cookie module.
+.TP
+.B urldebug
+This variable is the level of debugging output about URL parsing.
+.TP
+.B acceptcookies
+This flag controls whether to accept cookies presented by remote web servers.
+(Cookies are described below, in the discussion of the
+.B cookies
+file.)
+The values
+.B on
+and
+.B off
+are synonymous with
+.B 1
+and
+.BR 0 .
+The default is
+.BR on .
+.TP
+.B sendcookies
+This flag controls whether to present stored cookies to remote web servers.
+The default is
+.BR on .
+.TP
+.B redirectlimit
+Web servers can respond to a request with a message
+redirecting to another page.
+.I Webfs
+makes no effort to determine whether it is in an infinite
+redirect loop.
+Instead, it gives up after this many redirects.
+The default is
+.BR 10 .
+.TP
+.B useragent
+.I Webfs
+sends the value of this attribute in its
+.B User-Agent:
+header in its HTTP requests.
+The default is
+.RB `` "webfs/2.0 (plan 9)" .''
+.PD
+.PP
+The top-level directory also contains
+numbered directories corresponding to connections, which
+may be used to fetch a single URL.
+To allocate a connection, open the
+.B clone
+file and read a number 
+.I n
+from it.
+After opening, the
+.B clone
+file is equivalent to the file
+.IB n /ctl \fR.
+A connection is assumed closed once all files in its directory
+have been closed, and is then will be reallocated.
+.PP
+Each connection has its own private set of
+.BR acceptcookies ,
+.BR sendcookies ,
+.BR redirectlimit ,
+and
+.B useragent
+variables, initialized to the defaults set in the
+root's
+.B ctl
+file.  The per-connection
+.B ctl
+file allows editing the variables for this particular connection.
+.PP
+Each connection also has a URL string variable
+.B url
+associated with it.
+This URL may be an absolute URL such as
+.I http://www.lucent.com/index.html
+or a relative URL such as
+.IR ../index.html .
+The
+.B baseurl
+string variable sets the URL against which relative URLs
+are interpreted.
+Once the URL has been set,
+its pieces can be retrieved via individual files in the
+.B parsed
+directory.
+.I Webfs
+parses the following URL syntaxes; names in italics are
+the names of files in the
+.B parsed
+directory.
+.IP
+\fIscheme\f5:\fIschemedata
+.br
+\f5http://\fIhost\f5/\fIpath\fR[\f5?\fIquery\fR][\f5#\fIfragment\fR]
+.br
+\f5ftp://\fR[\fIuser\fR[\f5:\fIpassword\fR]\f5@\fR]\fP\f5\fIhost\f5/\fIpath\fR[\f5;type=\fIftptype\fR]
+.br
+\f5file:\fIpath
+.LP
+If there is associated data to be
+posted with the request, it can be written to
+.BR postbody .
+Finally, opening
+.B body
+initiates the request.
+The resulting data may be read from
+.B body
+as it arrives.
+After the request has been executed, the MIME content type
+may be read from the
+.B contenttype
+file.
+.PP
+The top-level
+.B cookies
+file contains the internal set of HTTP cookies, which
+are used by HTTP servers to associate requests with persistent
+state such as user profiles.
+It may be edited as an ordinary text file.
+Multiple instances of
+.I webfs
+and
+.IR webcookies (4)
+share cookies by keeping their internal set
+consistent with the
+.I cookiefile
+(default
+.BR $home/lib/webcookies ),
+which has the same format.
+.PP
+These files contain one line per cookie;
+each cookie comprises some number of
+.IB attr = value
+pairs.
+Cookie attributes are:
+.TP
+.BI name= name
+The name of the cookie on the remote server.
+.TP
+.BI value= value
+The value associated with that name on the remote server.
+The actual data included when a cookie is sent back
+to the server is
+.IB \fR``\fIname = value\fR''
+(where, confusingly,
+.I name
+and
+.I value
+are the values associated with the
+.B name
+and
+.B value
+attributes.
+.TP
+.BI domain= domain
+If
+.I domain
+is an IP address, the cookie can only be used for URLs
+with
+.I host
+equal to that IP address.
+Otherwise,
+.I domain
+must be a pattern beginning with a dot, and
+the cookie can only be used for URLs with a
+.I host
+having
+.I domain
+as a suffix.
+For example, a cookie with
+.B domain=.bell-labs.com
+may be used on hosts
+.I www.bell-labs.com
+and
+.IR www.research.bell-labs.com
+(but not
+.IR www.not-bell-labs.com ).
+.TP
+.BI path= path
+The cookie can only be used for URLs with a path
+beginning with
+.IR path .
+.TP
+.BI version= version
+The version of the HTTP cookie specification, specified by the server.
+.TP
+.BI comment= comment
+A comment, specified by the server.
+.TP
+.BI expire= expire
+The cookie expires at time
+.IR expire ,
+which is a decimal number of seconds since the epoch.
+.TP
+.B secure=1
+The cookie may only be used over secure
+.RB ( https )
+connections.
+Secure connections are currently unimplemented.
+.TP
+.B explicitdomain=1
+The domain associated with this cookie was set by
+the server (rather than inferred from a URL).
+.TP
+.B explicitpath=1
+The path associated with this cookie was set by the
+server (rather than inferred from a URL).
+.TP
+.B netscapestyle=1
+The server presented the cookie in ``Netscape style,'' which
+does not conform to the cookie standard, RFC2109.
+It is assumed that when presenting the cookie to the server,
+it must be sent back in Netscape style as well.
+.PD
+.SH EXAMPLE
+.B /sys/src/cmd/webfs/webget.c
+is a simple client.
+.SH SOURCE
+.B /sys/src/cmd/webfs
+.SH SEE ALSO
+.IR hget (1),
+.IR webcookies (4)
+.SH BUGS
+It's not clear what the relationship between
+.IR hget ,
+.I webcookies
+and
+.I webfs
+should be.
diff --git a/sys/man/4/wikifs b/sys/man/4/wikifs
new file mode 100755
index 000000000..2f19597f6
--- /dev/null
+++ b/sys/man/4/wikifs
@@ -0,0 +1,339 @@
+.TH WIKIFS 4
+.SH NAME
+wikifs, wikipost \- wiki file system
+.SH SYNOPSIS
+.B wikifs
+[
+.B -DM
+]
+[
+.B -a
+.I announce
+]...
+[
+.B -m
+.I mtpt
+]
+[
+.B -p
+.I perm
+]
+[
+.B -s
+.I service
+]
+.I dir
+.PP
+.B ip/httpd/wikipost
+.RB [ -b
+.IR inbuf ]
+.RB [ -d
+.IR domain ]
+.RB [ -r
+.IR remoteip ]
+.RB [ -w
+.IR webroot ]
+.RB [ -N
+.IR netdir ]
+.I method version uri
+.RI [ search ]
+.SH DESCRIPTION
+A
+.I wiki
+is a web server that facilitates easy editing of the pages it contains.
+.I Wikifs
+presents a wiki in two forms: as web pages to be served
+via
+.IR httpd (8)
+and as text files to be viewed via the
+.IR acme (1)
+wiki client
+(see
+.BR /acme/wiki/guide ).
+.PP
+.I Wikifs
+presents a file system interface to the wiki data stored
+in
+.IR dir .
+By default,
+.I wikifs
+mounts itself at
+.BR /mnt/wiki ;
+the
+.B -m
+flag specifies a different mount point,
+and the
+.B -M
+flag causes
+.I wikifs
+not to mount at all.
+.I Wikifs
+also announces 9P network services on the addresses
+given as arguments to
+.B -a
+options.
+If the
+.B -s
+option is given,
+.I wikifs
+will post a service file descriptor in
+.BI /srv/ service
+with permission
+.I perm
+(default 600).
+The
+.B -D
+flag causes a transcript of the 9P conversation
+to be written to standard error.
+.PP
+The wiki holds both the current pages and also
+all versions of all pages that have ever existed.
+All pages have time stamps associated with them.
+When a user wants to edit a page, he reads the 
+current page from the wiki, noting the time stamp
+on the page.
+When a user writes changes to a page, he includes the time stamp
+of the page he started with.  If the page has been updated
+by someone else while he was editing, the write will fail.
+This is called a ``conflicting write.''
+The submission is still saved in the history, so that
+the user can compare the page he submitted with the changes
+that were made while he was editing.
+.PP
+Each version of each page is described by a text file containing 
+one or more metadata lines followed by the page contents.
+The metadata lines begin with a capital letter specifying the type of data.
+Currently the metadata types are:
+.TP
+.B D
+The date this page was written, in decimal seconds since the epoch.
+.TP
+.B A
+The author of this version of the page.  Typically the rest of the line
+takes the form
+.I name
+.IR ip-address .
+.TP
+.B X
+This page's contents were submitted but rejected due to a
+conflicting write.
+.PD
+.PP
+After the metadata comes the actual page contents; each line of
+page contents is prefixed with a
+.B #
+character.
+.PP
+The directory
+.IB dir /d
+contains all the wiki data.  Typically it is world-writable
+so that
+.I wikifs
+can run as none.
+Each page on the wiki has a unique sequence number
+.IR n ;
+for each page, the
+.B d
+directory contains three files
+.IR n ,
+.IB n .hist \fR,
+and
+.BI L .n \fR.
+The file
+.I n
+holds the current version of the page: the first line of
+.I n
+is the page title, followed by page metadata and contents as described above.
+The append-only file
+.IB n .hist
+holds the history of the page.
+The first line of
+.IB n .hist
+is the title of the page.
+The rest of the file is the metadata and contents of every
+version of the page that has been submitted to the wiki.
+.BI L .n
+is a lock file for the page: it must be 
+held while reading or writing
+.I n
+and
+.IB n .hist \fR.
+The lock files allow multiple instances of
+.I wikifs
+to coexist peacefully.
+Finally, the
+.B map
+file (with associated lock
+.BR L.map )
+provides a mapping from
+sequence numbers to
+to page titles.
+Each map line is a decimal
+.IR n ,
+a single space,
+and then the title.
+Since titles are presented as names by
+.IR wikifs ,
+they cannot contain slashes.
+.PP
+.I Wikifs
+presents a three-level file system.
+The top level contains per-page directories
+named by the page titles with spaces turned
+into underscores.
+Each page also has a number associated with it
+(see the discussion of the wiki data files below).
+The number corresponding to a page may
+also be used to access it, although directory
+listings will always present the title.
+The
+.B new
+file is used to add new or revised pages to the wiki:
+writes to the file should be in the usual textual format:
+a title line, metadata lines, and page contents.
+Once all the contents have been written, a final zero-length
+message should be written to mark the end of the page.
+This last write will return an error if a conflicting
+write has occurred.
+After writing the file, the client may read from
+.B new
+to obtain the canonical title for the page, as presented
+by the file system.
+.PP
+The page directories contain subdirectories representing
+the history of the page, named
+by the decimal time stamp corresponding to each version.
+In addition to these history directories,
+the page directories contain the following files:
+.TP
+.B current
+The current raw data file for the page.
+.TP
+.B diff.html
+A web page listing the contents of every version of
+the page that has ever appeared on the wiki.
+The text is grey by default:
+differences between versions appear in black.
+.TP
+.B edit.html
+A web form for editing the the current version of the page.
+.TP
+.B history.html
+A web page listing the time stamps of the historical versions of the page.
+Each time stamp links to a page showing just
+that version.
+.TP
+.B history.txt
+A textual formatting of the history.  Each time stamp is prefixed with
+the name of the directory corresponding to that version.
+.TP
+.B index.html
+An HTML formatting of the current version of the page.
+.TP
+.B index.txt
+A textual formatting of the current version of the page.
+.TP
+.B werror.html
+An HTML error page to be returned by
+.I wikipost
+on conflicting writes.
+.PD
+.LP
+The HTML files are generated from the templates with the same names
+in
+.IR dir ,
+except that
+.B index.html
+and
+.B index.txt
+are generated from the templates
+.B page.html
+and
+.BR page.txt .
+.PP
+The history directories
+are similar to the page directories but only contain
+.BR current ,
+.BR index.html ,
+and
+.BR index.txt .
+This
+.B index.html
+and
+.B index.txt
+are generated from the templates
+.B oldpage.html
+and
+.BR oldpage.txt .
+.PP
+The
+.IR httpd (8)
+helper program
+.I wikipost
+is used to process editing requests posted
+to the web server by users.
+It expects the posted form to contain these
+(usually hidden) fields:
+.BR TITLE ,
+the title of the page;
+.BR VERSION ,
+the time stamp of the page that is being edited;
+.BR service ,
+the service name associated with this wiki
+.RI ( wikipost
+looks for
+.BI /srv/wiki. service \fR);
+and
+.BR base ,
+the base for wiki URLs in the response.
+.PP
+After mounting the wiki,
+.I wikipost
+writes a page update request to
+.B /mnt/wiki/new
+and then returns the contents of one HTML
+file in
+.BR /mnt/wiki/ title \fR.
+If the write succeeds,
+.I wikipost
+returns
+.BR index.html .
+if the write fails due to a conflicting write,
+.I wikipost
+returns
+.BR werror.html .
+.SH EXAMPLE
+The Plan 9 wiki at Bell Labs is started by running:
+.EX
+.ta +4n
+	wikifs -p 666 -s wiki.plan9 -a tcp!*!wiki /sys/lib/wiki
+.EE
+.PP
+The wiki is mounted for
+.IR httpd (8)
+by an entry in
+.BR /lib/namespace.httpd :
+.EX
+.ta +4n
+	# wiki
+	mount -b #s/wiki.plan9 /usr/web/wiki/plan9
+.EE
+Notice that the wiki service was explicitly posted with
+mode 666 so that
+.I httpd
+(running as none)
+would be able to mount it.
+.PP
+In the Plan 9 distribution, the directory
+.B /sys/lib/wiki
+contains sample files similar to those used
+to start the current Plan 9 wiki.
+.SH SOURCE
+.B /sys/src/cmd/wikifs
+.br
+.B /sys/src/cmd/ip/httpd/wikipost.c
+.SH SEE ALSO
+The original wiki,
+.B http://c2.com/cgi/wiki?WikiWikiWeb
+.br
+.B /acme/wiki/guide
author	Taru Karttunen <taruti@taruti.net>	2011-03-30 16:49:47 +0300
committer	Taru Karttunen <taruti@taruti.net>	2011-03-30 16:49:47 +0300
commit	b41b9034225ab3e49980d9de55c141011b6383b0 (patch)
tree	891014b4c2e803e01ac7a1fd2b60819fbc5a6e73 /sys/man/4
parent	c558a99e0be506a9abdf677f0ca4490644e05fc1 (diff)