--- hurd.texi.afterfirstpatch	Fri Sep  6 00:51:54 2002
+++ hurd.texi	Sat Sep  7 01:39:09 2002
@@ -4645,12 +4645,101 @@
 who want their filesystems to be rigidly tree-structured.@footnote{You
 are lost in a maze of twisty little filesystems, all alike@dots{}.}
 
-FIXME: finish
+@menu
+* Invoking symlink::            The symbolic link translator.
+* Invoking firmlink::           A half-way between symbolic and hard links.
+* Invoking hostmux::            The host multiplexer.
+* Invoking usermux::            The user multiplexer.
+@end menu
+
+@c @section shadowfs
+
+@node Invoking symlink
+@section Invoking @code{symlink}
+
+The @code{symlink} translator refers to another file.  It does not
+contain any actualy reference to that file.  Instead, @code{symlink}
+points to its target `by name'.  Therefore, the file will be looked up
+in the clients namespace.
+
+The @code{symlink} program must be started as a translator (e.g. with
+@code{settrans} @ref{Invoking settrans}) and has the following
+synopsis:
+
+@example
+symlink @var{target}
+@end example
+
+It does not accept any options.
+
+Many filesystems may want to implement the semantics of this
+translator on their own, so that no symlink process must be started.
+
+@node Invoking firmlink
+@section Invoking @code{firmlink}
+
+The @code{firmlink} translator, like the @code{symlink} @ref{Invoking
+symlink}, refers to another file.  It also works `by name', thus does
+not hold a reference to the target.  The target will be looked up
+in the namespace of the @code{firmlink} translator, therfore it will
+work over the boundaries of a chroot, just like a hard link would.
+Additionaly, later parent lookups will go through the link, not
+through the target, so that for example a `cd ..' will actually work
+like for a hard-linked directory.
+
+The @code{firmlink} program must be started as a translator (e.g. with
+@code{settrans} @ref{Invoking settrans}) and has the following
+synopsis:
+
+@example
+firmlink @var{target}
+@end example
 
-@section symlink, firmlink
-@section hostmux, usermux
-@section shadowfs
+It does not accept any options.
 
+@node Invoking hostmux
+@section Invoking @code{hostmux}
+
+The @code{hostmux} translator provides a directory in which hostnames
+can be looked up, and will start another translator to service each
+resulting node.  There will only be one node per host, so that for
+example looking up the same host once with its IP address and once
+with its hostname will not start two separate translators.
+
+The @code{hostmux} program must be started as a translator (e.g. with
+@code{settrans} @ref{Invoking settrans}) and has the following
+synopsis:
+
+@example
+hostmux [@var{option}@dots{}] @var{translator} [@var{arg}@dots{}]
+@end example
+
+It accepts the following option:
+
+@table @code
+
+@item -H @var{pattern}
+@itemx --host-pattern=@var{pattern}
+The string @code{pattern} will be replaced with the hostname in the
+translator specification.  The default is `$@{host@}'.  If this is
+empty, or the string does not occur, the hostname will be appended at
+the end.
+
+@end table
+
+An example of how to use the @code{hostmux} translator is to let it
+start an ftpfs translator for every host subdirectory that is looked
+up:
+
+@example
+settrans -c /ftp /hurd/hostmux /hurd/ftpfs '$@{host@}:/'
+ls /ftp/alpha.gnu.org/gnu/hurd/
+@end example
+
+@node Invoking usermux
+@section Invoking @code{usermux}
+
+FIXME: finish
 
 @node Distributed Filesystems
 @chapter Distributed Filesystems