Look Ma' what I found on my harddisk ...

 o New faster syscalls for 2.1.x, too
 o Upgrade to 2.1.89.

Don't try to run this.  It's flaky as hell.  But feel free to debug ...

8 files changed, 582 insertions, 84 deletions

diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt
index bc892a75b..4c5d7fa7a 100644
--- a/Documentation/filesystems/affs.txt
+++ b/Documentation/filesystems/affs.txt
@@ -65,6 +65,11 @@ quiet		The file system will not return an error for disallowed
 verbose		The volume name, file system type and block size will
 		be written to the syslog when the filesystem is mounted.
 
+mufs		The filesystem is really a muFS, also it doesn't
+		identify itself as one. This option is neccessary if
+		the filesystem wasn't formatted as muFS, but is used
+		as one.
+
 prefix=path	Path will be prefixed to every absolute path name of
 		symbolic links on an AFFS partition. Default = /
 
diff --git a/Documentation/filesystems/coda.txt b/Documentation/filesystems/coda.txt
index 829fd2d20..f049c02a6 100644
--- a/Documentation/filesystems/coda.txt
+++ b/Documentation/filesystems/coda.txt
@@ -1,3 +1,27 @@
+
+NOTE: 
+This is one of the technical documents describing a component of
+Coda -- this document describes the client kernel-Venus interface.
+
+For more information:
+  http://www.coda.cs.cmu.edu
+For user level software needed to run Coda:
+  ftp://ftp.coda.cs.cmu.edu
+
+To run Coda you need to get a user level cache manager for the client,
+named Venus, as well as tools to manipulate ACL's, to log in etc.  The
+client needs to have the Coda filesystem selected in the kernel
+configuration.
+
+The server needs a user level server and at present does not depend on
+kernel support.
+
+
+
+
+
+
+
   The Venus kernel interface
   Peter J. Braam
   v1.0, Nov 9, 1997
@@ -8,103 +32,128 @@
   (version 1.0) as well as improvements we envisage.
   ______________________________________________________________________
 
-  Table of Contents:
+  Table of Contents
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
-  1.      Introduction
 
-  2.      Servicing Coda filesystem calls
 
-  3.      The message layer
 
-  3.1.    Implementation details
 
-  4.      The interface at the call level
 
-  4.1.    Data structures shared by the kernel and Venus
 
-  4.2.    The pioctl interface
 
-  4.3.    root
 
-  4.4.    lookup
 
-  4.5.    getattr
 
-  4.6.    setattr
 
-  4.7.    access
 
-  4.8.    create
 
-  4.9.    mkdir
 
-  4.10.   link
 
-  4.11.   synlink
 
-  4.12.   remove
 
-  4.13.   rmdir
 
-  4.14.   readlink
 
-  4.15.   open
 
-  4.16.   close
 
-  4.17.   ioctl
 
-  4.18.   rename
 
-  4.19.   readdir
 
-  4.20.   vget
 
-  4.21.   fsync
 
-  4.22.   inactive
 
-  4.23.   rdwr
 
-  4.24.   odymount
 
-  4.25.   ody_lookup
 
-  4.26.   ody_expand
 
-  4.27.   prefetch
 
-  4.28.   signal
 
-  5.      The minicache and downcalls
 
-  5.1.    INVALIDATE
 
-  5.2.    FLUSH
+  1. Introduction
 
-  5.3.    PURGEUSER
+  2. Servicing Coda filesystem calls
 
-  5.4.    ZAPFILE
+  3. The message layer
 
-  5.5.    ZAPDIR
+     3.1 Implementation details
 
-  5.6.    ZAPVNODE
+  4. The interface at the call level
 
-  5.7.    PURGEFID
+     4.1 Data structures shared by the kernel and Venus
+     4.2 The pioctl interface
+     4.3 root
+     4.4 lookup
+     4.5 getattr
+     4.6 setattr
+     4.7 access
+     4.8 create
+     4.9 mkdir
+     4.10 link
+     4.11 symlink
+     4.12 remove
+     4.13 rmdir
+     4.14 readlink
+     4.15 open
+     4.16 close
+     4.17 ioctl
+     4.18 rename
+     4.19 readdir
+     4.20 vget
+     4.21 fsync
+     4.22 inactive
+     4.23 rdwr
+     4.24 odymount
+     4.25 ody_lookup
+     4.26 ody_expand
+     4.27 prefetch
+     4.28 signal
 
-  5.8.    REPLACE
+  5. The minicache and downcalls
+
+     5.1 INVALIDATE
+     5.2 FLUSH
+     5.3 PURGEUSER
+     5.4 ZAPFILE
+     5.5 ZAPDIR
+     5.6 ZAPVNODE
+     5.7 PURGEFID
+     5.8 REPLACE
+
+  6. Initialization and cleanup
+
+     6.1 Requirements
 
-  6.      Initialization and cleanup
 
-  6.1.    Requirements
   ______________________________________________________________________
   0wpage
 
   11..  IInnttrroodduuccttiioonn
 
+
+
   A key component in the Coda Distributed File System is the cache
   manager, _V_e_n_u_s.
 
+
   When processes on a Coda enabled system access files in the Coda
   filesystem, requests are directed at the filesystem layer in the
   operating system. The operating system will communicate with Venus to
@@ -168,7 +217,7 @@
   the Coda FS layer, so the Coda FS driver must expose the VFS interface
   as applicable in the operating system. These differ very significantly
   among operating systems, but share features such as facilities to
-  read/write and create and remove object.  The Coda FS layer services
+  read/write and create and remove objects.  The Coda FS layer services
   such VFS requests in by invoking on or more well defined services
   offered by the cache manager Venus.  When the replies from Venus have
   come back to the FS driver, servicing of the VFS call continues and
@@ -176,13 +225,18 @@
   returns to the process.
 
   As a result of this design a basic interface exposed by the FS driver
-  must allow Venus to handle manage message traffic.  In particular
-  Venus must be able to retrieve and place messages and to be notified
-  of the arrival of a new message. The notification must be through a
-  mechanism which does not block Venus since Venus must attend to other
-  tasks even when no messages are waiting or being processed.
+  must allow Venus to manage message traffic.  In particular Venus must
+  be able to retrieve and place messages and to be notified of the
+  arrival of a new message. The notification must be through a mechanism
+  which does not block Venus since Venus must attend to other tasks even
+  when no messages are waiting or being processed.
+
+
 
-                       Interfaces of Coda FS Driver
+
+
+
+                     Interfaces of the Coda FS Driver
 
   Furthermore the FS layer provides for a special path of communication
   between a user process and Venus, called the pioctl interface. The
@@ -210,8 +264,10 @@
 
   33..  TThhee mmeessssaaggee llaayyeerr
 
+
+
   At the lowest level the communication between Venus and the FS driver
-  proceeds through messages.  The synchronization of between processes
+  proceeds through messages.  The synchronization between processes
   requesting Coda file service and Venus relies on blocking and waking
   up processes.  The Coda FS driver processes VFS- and pioctl-requests
   on behalf of a process P, creates messages for Venus, awaits replies
@@ -256,6 +312,7 @@
   namely when Venus calls sendmsg_to_kernel.  At this moment the Coda FS
   driver looks at the contents of the message and decides if:
 
+
   +o  the message is a reply for a suspended thread P.  If so it removes
      the message from the processing queue and marks the message as
      WRITTEN.  Finally, the FS driver unblocks P (still in the kernel
@@ -266,7 +323,7 @@
 
   +o  The message is a _d_o_w_n_c_a_l_l.  A downcall is a request from Venus to
      the FS Driver. The FS driver processes the request immediately
-     (usually a cach eviction or replacement) and when finishes
+     (usually a cache eviction or replacement) and when finishes
      sendmsg_to_kernel returns.
 
   Now P awakes and continues processing upcall.  There are some
@@ -277,6 +334,12 @@
   deallocate message structure and return.  The FS routine can proceed
   with its processing.
 
+
+
+
+
+
+
                       Sleeping and IPC arrangements
 
   In case P is woken up by a signal and not by Venus, it will first look
@@ -291,6 +354,8 @@
   extra field "handle_signals" could be added in the message structure
   to indicate points of no return have been passed.--)
 
+
+
   33..11..  IImmpplleemmeennttaattiioonn ddeettaaiillss
 
   The Unix implementation of this mechanism has been through the
@@ -312,11 +377,13 @@
 
   44..  TThhee iinntteerrffaaccee aatt tthhee ccaallll lleevveell
 
+
   This section describes the upcalls a Coda FS driver can make to Venus.
   Each of these upcalls make use of two structures: inputArgs and
   outputArgs.   In pseudo BNF form the structures take the following
   form:
 
+
   struct inputArgs {
       u_long opcode;
       u_long unique;     /* Keep multiple outstanding msgs distinct */
@@ -335,6 +402,8 @@
       <union "out" of call dependent parts of inputArgs>
   };
 
+
+
   Before going on let us elucidate the role of the various fields. The
   inputArgs start with the opcode which defines the type of service
   requested from Venus. There are approximately 30 upcalls at present
@@ -346,8 +415,12 @@
   Before delving into the specific calls we need to discuss a variety of
   data structures shared by the kernel and Venus.
 
+
+
+
   44..11..  DDaattaa ssttrruuccttuurreess sshhaarreedd bbyy tthhee kkeerrnneell aanndd VVeennuuss
 
+
   The CodaCred structure defines a variety of user and group id's as
   they are set for the calling process. The vuid_t and guid_t are 32 bit
   unsigned integers.  It also defines group member ship in an array.  On
@@ -361,10 +434,13 @@
       vgid_t cr_groups[NGROUPS];        /* Group membership for caller */
   };
 
+
+
   NNOOTTEE It is questionable if we need CodaCreds in Venus. Finally Venus
   doesn't know about groups, although it does create files with the
   default uid/gid.  Perhaps the list of group membership is superfluous.
 
+
   The next item is the fundamental identifier used to identify Coda
   files, the ViceFid.  A fid of a file uniquely defines a file or
   directory in the Coda filesystem within a _c_e_l_l.   (-- A _c_e_l_l is a
@@ -372,12 +448,15 @@
   control machine or SCM. See the Coda Administration manual for a
   detailed description of the role of the SCM.--)
 
+
   typedef struct ViceFid {
       VolumeId Volume;
       VnodeId Vnode;
       Unique_t Unique;
   } ViceFid;
 
+
+
   Each of the constituent fields: VolumeId, VnodeId and Unique_t are
   unsigned 32 bit integers.  We envisage that a further field will need
   to be prefixed to identify the Coda cell; this will probably take the
@@ -388,6 +467,23 @@
   exchange information.  It has room for future extensions such as
   support for device files (currently not present in Coda).
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
   struct coda_vattr {
           enum coda_vtype va_type;        /* vnode type (for create) */
           u_short         va_mode;        /* files access mode and type */
@@ -410,9 +506,13 @@
           long            va_spare;       /* remain quad aligned */
   };
 
+
+
+
   44..22..  TThhee ppiiooccttll iinntteerrffaaccee
 
-  Coda specific requests can be made by application through a pioctl
+
+  Coda specific requests can be made by application through the pioctl
   interface. The pioctl is implemented as an ordinary ioctl on a
   ficticious file /coda/.CONTROL.  The piocl call opens this file, gets
   a file handle and makes the ioctl call. Finally it closes the file.
@@ -429,14 +529,19 @@
           int follow;
       } data;
 
+
+
   where
 
+
   struct ViceIoctl {
           caddr_t in, out;        /* Data to be transferred in, or out */
           short in_size;          /* Size of input buffer <= 2K */
           short out_size;         /* Maximum size of output buffer, <= 2K */
   };
 
+
+
   The path must be a Coda file, otherwise the ioctl upcall will not be
   made.
 
@@ -449,6 +554,7 @@
 
   44..33..  rroooott
 
+
   AArrgguummeennttss
 
      iinn empty
@@ -459,6 +565,8 @@
                     ViceFid VFid;
                 } cfs_root;
 
+
+
   DDeessccrriippttiioonn This call is made to Venus during the initialization of
   the Coda filesystem. If the result is zero, the cfs_root structure
   contains the ViceFid of the root of the Coda filesystem. If a non-zero
@@ -470,6 +578,7 @@
 
   44..44..  llooookkuupp
 
+
   SSuummmmaarryy Find the ViceFid and type of an object in a directory if it
   exists.
 
@@ -482,6 +591,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_lookup;
 
+
+
      oouutt
 
                 struct cfs_lookup_out {
@@ -489,6 +600,8 @@
                     int vtype;
                 } cfs_lookup;
 
+
+
   DDeessccrriippttiioonn This call is made to determine the ViceFid and filetype of
   a directory entry.  The directory entry requested carries name name
   and Venus will search the directory identified by cfs_lookup_in.VFid.
@@ -512,6 +625,7 @@
 
   44..55..  ggeettaattttrr
 
+
   SSuummmmaarryy Get the attributes of a file.
 
   AArrgguummeennttss
@@ -523,12 +637,16 @@
                     struct coda_vattr attr; /* XXXXX */
                 } cfs_getattr;
 
+
+
      oouutt
 
                 struct cfs_getattr_out {
                     struct coda_vattr attr;
                 } cfs_getattr;
 
+
+
   DDeessccrriippttiioonn This call returns the attributes of the file identified by
   fid.
 
@@ -549,6 +667,7 @@
 
   44..66..  sseettaattttrr
 
+
   SSuummmmaarryy Set the attributes of a file.
 
   AArrgguummeennttss
@@ -560,6 +679,9 @@
                     struct coda_vattr attr;
                 } cfs_setattr;
 
+
+
+
      oouutt
         empty
 
@@ -577,6 +699,7 @@
 
   44..77..  aacccceessss
 
+
   SSuummmmaarryy
 
   AArrgguummeennttss
@@ -588,11 +711,13 @@
                     int flags;
                 } cfs_access;
 
+
+
      oouutt
         empty
 
   DDeessccrriippttiioonn Verify if access to the object identified by VFid for
-  operetions described by flags is permitted.  The result indicates if
+  operations described by flags is permitted.  The result indicates if
   access will be granted.  It is important to remember that Coda uses
   ACL's to enforce protection and that ultimately the servers, not the
   clients enforce the security of the system.  The result of this call
@@ -605,6 +730,7 @@
 
   44..88..  ccrreeaattee
 
+
   SSuummmmaarryy Invoked to create a file
 
   AArrgguummeennttss
@@ -619,6 +745,9 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_create;
 
+
+
+
      oouutt
 
                 struct cfs_create_out {
@@ -626,6 +755,8 @@
                     struct coda_vattr attr;
                 } cfs_create;
 
+
+
   DDeessccrriippttiioonn  This upcall is invoked to request creation of a file.
   The file will be created in the directory identified by VFid, its name
   will be name, and the mode will be mode.  If excl is set an error will
@@ -637,6 +768,7 @@
   instantiate a vnode, inode or filehandle at kernel level for the new
   object.
 
+
   EErrrroorrss A variety of errors can occur. Permissions may be insufficient.
   If the object exists and is not a file the error EISDIR is returned
   under Unix.
@@ -657,6 +789,7 @@
 
   44..99..  mmkkddiirr
 
+
   SSuummmmaarryy Create a new directory.
 
   AArrgguummeennttss
@@ -669,6 +802,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_mkdir;
 
+
+
      oouutt
 
                 struct cfs_mkdir_out {
@@ -676,6 +811,9 @@
                     struct coda_vattr attr;
                 } cfs_mkdir;
 
+
+
+
   DDeessccrriippttiioonn This call is similar to create but creates a directory.
   Only the mode field in the input parameters is used for creation.
   Upon successful creation, the attr returned contains the attributes of
@@ -693,6 +831,7 @@
 
   44..1100..  lliinnkk
 
+
   SSuummmmaarryy Create a link to an existing file.
 
   AArrgguummeennttss
@@ -705,6 +844,8 @@
                     char        *tname;         /* Place holder for data. */
                 } cfs_link;
 
+
+
      oouutt
         empty
 
@@ -716,7 +857,8 @@
 
   EErrrroorrss The usual errors can occur.0wpage
 
-  44..1111..  ssyynnlliinnkk
+  44..1111..  ssyymmlliinnkk
+
 
   SSuummmmaarryy create a symbolic link
 
@@ -731,12 +873,14 @@
                     char        *tname;
                 } cfs_symlink;
 
+
+
      oouutt
         none
 
   DDeessccrriippttiioonn Create a symbolic link. The link is to be placed in the
   directory identified by VFid and named tname.  It should point to the
-  pathname srcname.  The attributes of the newly creaeted object are to
+  pathname srcname.  The attributes of the newly created object are to
   be set to attr.
 
   EErrrroorrss
@@ -748,6 +892,7 @@
 
   44..1122..  rreemmoovvee
 
+
   SSuummmmaarryy Remove a file
 
   AArrgguummeennttss
@@ -759,6 +904,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_remove;
 
+
+
      oouutt
         none
 
@@ -774,6 +921,7 @@
 
   44..1133..  rrmmddiirr
 
+
   SSuummmmaarryy Remove a directory
 
   AArrgguummeennttss
@@ -785,6 +933,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_rmdir;
 
+
+
      oouutt
         none
 
@@ -800,6 +950,7 @@
 
   44..1144..  rreeaaddlliinnkk
 
+
   SSuummmmaarryy Read the value of a symbolic link.
 
   AArrgguummeennttss
@@ -810,6 +961,8 @@
                     ViceFid VFid;
                 } cfs_readlink;
 
+
+
      oouutt
 
                 struct cfs_readlink_out {
@@ -817,6 +970,8 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_readlink;
 
+
+
   DDeessccrriippttiioonn This routine reads the contents of symbolic link
   identified by VFid into the buffer data.  The buffer data must be able
   to hold any name up to CFS_MAXNAMLEN (PATH or NAM??).
@@ -827,6 +982,7 @@
 
   44..1155..  ooppeenn
 
+
   SSuummmmaarryy Open a file.
 
   AArrgguummeennttss
@@ -838,6 +994,8 @@
                     int flags;
                 } cfs_open;
 
+
+
      oouutt
 
                 struct cfs_open_out {
@@ -845,6 +1003,8 @@
                     ino_t       inode;
                 } cfs_open;
 
+
+
   DDeessccrriippttiioonn  This request asks Venus to place the file identified by
   VFid in its cache and to note that the calling process wishes to open
   it with flags as in open(2).  The return value to the kernel differs
@@ -852,7 +1012,6 @@
   informed of the device and inode number of the container file in the
   fields dev and inode.  For Windows the path of the container file is
   returned to the kernel.
-
   EErrrroorrss
 
   NNOOTTEE Currently the cfs_open_out structure is not properly adapted to
@@ -864,6 +1023,7 @@
 
   44..1166..  cclloossee
 
+
   SSuummmmaarryy Close a file, update it on the servers.
 
   AArrgguummeennttss
@@ -875,6 +1035,8 @@
                     int flags;
                 } cfs_close;
 
+
+
      oouutt
         none
 
@@ -896,6 +1058,7 @@
 
   44..1177..  iiooccttll
 
+
   SSuummmmaarryy Do an ioctl on a file. This includes the piocl interface.
 
   AArrgguummeennttss
@@ -910,13 +1073,18 @@
                     char *data;                 /* Place holder for data. */
                 } cfs_ioctl;
 
+
+
      oouutt
 
+
                 struct cfs_ioctl_out {
                     int len;
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_ioctl;
 
+
+
   DDeessccrriippttiioonn Do an ioctl operation on a file.  The command, len and
   data arguments are filled as usual.  flags is not used by Venus.
 
@@ -925,10 +1093,12 @@
   NNOOTTEE Another bogus parameter.  flags is not used.  What is the
   business about PREFETCHING in the Venus' code?
 
+
   0wpage
 
   44..1188..  rreennaammee
 
+
   SSuummmmaarryy Rename a fid.
 
   AArrgguummeennttss
@@ -942,6 +1112,8 @@
                     char        *destname;
                 } cfs_rename;
 
+
+
      oouutt
         none
 
@@ -956,6 +1128,7 @@
 
   44..1199..  rreeaaddddiirr
 
+
   SSuummmmaarryy Read directory entries.
 
   AArrgguummeennttss
@@ -968,6 +1141,9 @@
                     int offset;
                 } cfs_readdir;
 
+
+
+
      oouutt
 
                 struct cfs_readdir_out {
@@ -975,6 +1151,8 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_readdir;
 
+
+
   DDeessccrriippttiioonn Read directory entries from VFid starting at offset and
   read at most count bytes.  Returns the data into data and indicates
   the size returned size.
@@ -989,15 +1167,18 @@
 
   44..2200..  vvggeett
 
+
   SSuummmmaarryy instructs Venus to do an FSDB->Get.
 
   AArrgguummeennttss
 
      iinn
 
-                struct cfs_fsync_in {
+                struct cfs_vget_in {
                     ViceFid VFid;
-                } cfs_fsync;
+                } cfs_vget;
+
+
 
      oouutt
 
@@ -1006,6 +1187,8 @@
                     int vtype;
                 } cfs_vget;
 
+
+
   DDeessccrriippttiioonn This upcall asks Venus to do a get operation on an fsobj
   labelled by VFid.
 
@@ -1020,6 +1203,7 @@
 
   44..2211..  ffssyynncc
 
+
   SSuummmmaarryy Tell Venus to update the RVM attributes of a file.
 
   AArrgguummeennttss
@@ -1030,6 +1214,8 @@
                     ViceFid VFid;
                 } cfs_fsync;
 
+
+
      oouutt
         none
 
@@ -1045,6 +1231,7 @@
 
   44..2222..  iinnaaccttiivvee
 
+
   SSuummmmaarryy Tell Venus a vnode is no longer in use.
 
   AArrgguummeennttss
@@ -1055,6 +1242,8 @@
                     ViceFid VFid;
                 } cfs_inactive;
 
+
+
      oouutt
         none
 
@@ -1068,6 +1257,7 @@
 
   44..2233..  rrddwwrr
 
+
   SSuummmmaarryy Read or write from a file
 
   AArrgguummeennttss
@@ -1083,6 +1273,9 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_rdwr;
 
+
+
+
      oouutt
 
                 struct cfs_rdwr_out {
@@ -1091,6 +1284,8 @@
                     caddr_t     data;   /* Place holder for data. */
                 } cfs_rdwr;
 
+
+
   DDeessccrriippttiioonn This upcall asks Venus to read or write from a file.
 
   EErrrroorrss
@@ -1099,10 +1294,12 @@
   read/write operations never reach Venus.  I have been told the
   operation does not work.  It is not currently used.
 
+
   0wpage
 
   44..2244..  ooddyymmoouunntt
 
+
   SSuummmmaarryy Allows mounting multiple Coda "filesystems" on one Unix mount
   point.
 
@@ -1114,12 +1311,16 @@
                     char        *name;          /* Place holder for data. */
                 } ody_mount;
 
+
+
      oouutt
 
                 struct ody_mount_out {
                     ViceFid VFid;
                 } ody_mount;
 
+
+
   DDeessccrriippttiioonn  Asks Venus to return the rootfid of a Coda system named
   name.  The fid is returned in VFid.
 
@@ -1133,12 +1334,14 @@
 
   44..2255..  ooddyy__llooookkuupp
 
+
   SSuummmmaarryy Looks up something.
 
   AArrgguummeennttss
 
      iinn irrelevant
 
+
      oouutt
         irrelevant
 
@@ -1152,6 +1355,7 @@
 
   44..2266..  ooddyy__eexxppaanndd
 
+
   SSuummmmaarryy expands something in a dynamic set.
 
   AArrgguummeennttss
@@ -1171,6 +1375,7 @@
 
   44..2277..  pprreeffeettcchh
 
+
   SSuummmmaarryy Prefetch a dynamic set.
 
   AArrgguummeennttss
@@ -1188,10 +1393,12 @@
 
   NNOOTTEE Gut it. It isn't working and isn't used by Coda.
 
+
   0wpage
 
   44..2288..  ssiiggnnaall
 
+
   SSuummmmaarryy Send Venus a signal about an upcall.
 
   AArrgguummeennttss
@@ -1219,6 +1426,7 @@
 
   55..  TThhee mmiinniiccaacchhee aanndd ddoowwnnccaallllss
 
+
   The Coda FS Driver can cache results of lookup and access upcalls, to
   limit the frequency of upcalls.  Upcalls carry a price since a process
   context switch needs to take place.  The counterpart of caching the
@@ -1227,8 +1435,8 @@
 
   The kernel code generally has to maintain a structure which links the
   internal file handles (called vnodes in BSD, inodes in Linux and
-  FileHandles in Windows) with the ViceFid's which Venus maintains.
-  Ther reason is that frequent translations back and forth are needed in
+  FileHandles in Windows) with the ViceFid's which Venus maintains.  The
+  reason is that frequent translations back and forth are needed in
   order to make upcalls and use the results of upcalls.  Such linking
   objects are called ccnnooddeess.
 
@@ -1246,7 +1454,7 @@
   The lookup call in the Coda FS Driver may request the cnode of the
   desired object from the cache, by passing it's name, directory and the
   CodaCred's of the caller.  The cache will return the cnode or indicate
-  and it cannot be found.  The Coda FS Driver must be careful to
+  that it cannot be found.  The Coda FS Driver must be careful to
   invalidate cache entries when it modifies or removes objects.
 
   When Venus obtains information that indicates that cache entries are
@@ -1255,12 +1463,17 @@
   the kind described below.  The Coda FS Driver does not return an error
   unless the downcall data could not be read into kernel memory.
 
+
   55..11..  IINNVVAALLIIDDAATTEE
 
+
   No information is available on this call.
 
+
   55..22..  FFLLUUSSHH
 
+
+
   AArrgguummeennttss None
 
   SSuummmmaarryy Flush the name cache entirely.
@@ -1270,25 +1483,33 @@
   systems allow the kernel name cache to be switched off dynamically.
   When this is done, this downcall is made.
 
+
   55..33..  PPUURRGGEEUUSSEERR
 
+
   AArrgguummeennttss
 
           struct cfs_purgeuser_out {/* CFS_PURGEUSER is a venus->kernel call */
               struct CodaCred cred;
           } cfs_purgeuser;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache carrying the Cred.  This
   call is issued when tokes for a user expire or are flushed.
 
+
   55..44..  ZZAAPPFFIILLEE
 
+
   AArrgguummeennttss
 
           struct cfs_zapfile_out {  /* CFS_ZAPFILE is a venus->kernel call */
               ViceFid CodaFid;
           } cfs_zapfile;
 
+
+
   DDeessccrriippttiioonn Remove all entries which have the (dir vnode, name) pair.
   This is issued as a result of an invalidation of cached attributes of
   a vnode.
@@ -1297,20 +1518,28 @@
   zapfile routine takes different arguments. Linux does not implement
   the invalidation of attributes correctly.
 
+
+
   55..55..  ZZAAPPDDIIRR
 
+
   AArrgguummeennttss
 
           struct cfs_zapdir_out {   /* CFS_ZAPDIR is a venus->kernel call */
               ViceFid CodaFid;
           } cfs_zapdir;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache lying in a directory
   CodaFid, and all children of this directory. This call is issed when
-  Venus receives a callback on the this directory.
+  Venus receives a callback on the directory.
+
 
   55..66..  ZZAAPPVVNNOODDEE
 
+
+
   AArrgguummeennttss
 
           struct cfs_zapvnode_out { /* CFS_ZAPVNODE is a venus->kernel call */
@@ -1318,11 +1547,15 @@
               ViceFid VFid;
           } cfs_zapvnode;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache carrying the cred and VFid
   as in the arguments. This downcall is probably never issued.
 
+
   55..77..  PPUURRGGEEFFIIDD
 
+
   SSuummmmaarryy
 
   AArrgguummeennttss
@@ -1331,12 +1564,17 @@
               ViceFid CodaFid;
           } cfs_purgefid;
 
+
+
   DDeessccrriippttiioonn Flush the attribute for the file. If it is a dir (odd
   vnode), purge its children from the namecache remove the file from the
   namecache.
 
+
+
   55..88..  RREEPPLLAACCEE
 
+
   SSuummmmaarryy Replace the Fid's for a collection of names.
 
   AArrgguummeennttss
@@ -1346,6 +1584,8 @@
               ViceFid OldFid;
           } cfs_replace;
 
+
+
   DDeessccrriippttiioonn This routine replaces a ViceFid in the name cache with
   another.  It is added to allow Venus during reintegration to replace
   locally allocated temp fids while disconnected with global fids even
@@ -1355,11 +1595,13 @@
 
   66..  IInniittiiaalliizzaattiioonn aanndd cclleeaannuupp
 
+
   This section gives brief hints as to desirable features for the Coda
   FS Driver at startup and upon shutdown or Venus failures.  Before
   entering the discussion it is useful to repeat that the Coda FS Driver
   maintains the following data:
 
+
   1. message queues
 
   2. cnodes
@@ -1383,8 +1625,10 @@
      Currently the _p_i_o_c_t_l passes through the VFS for Coda so we can
      treat these similarly.
 
+
   66..11..  RReeqquuiirreemmeennttss
 
+
   The following requirements should be accomodated:
 
   1. The message queueus should have open and close routines.  On Unix
@@ -1399,6 +1643,7 @@
 
   +o  Close will free all memory allocated by the message queues.
 
+
   2. At open the namecache shall be initialized to empty state.
 
   3. Before the message queues are open, all VFS operations will fail.
@@ -1425,3 +1670,5 @@
   above requirements fully.  For smooth operation this needs to be
   corrected.
 
+
+
diff --git a/Documentation/filesystems/fat_cvf.txt b/Documentation/filesystems/fat_cvf.txt
new file mode 100644
index 000000000..9e7062e13
--- /dev/null
+++ b/Documentation/filesystems/fat_cvf.txt
@@ -0,0 +1,190 @@
+This is the main documentation for the CVF-FAT filesystem extension.  31DEC1997
+
+
+Table of Contents:
+
+1. The idea of CVF-FAT
+2. Restrictions
+3. Mount options
+4. Description of the CVF-FAT interface
+5. CVF Modules
+
+------------------------------------------------------------------------------
+
+
+1. The idea of CVF-FAT
+------------------------------------------------------------------------------
+
+CVF-FAT is a FAT filesystem extension that provides a generic interface for
+Compressed Volume Files in FAT partitions. Popular CVF software, for
+example, are Microsoft's Doublespace/Drivespace and Stac's Stacker.
+Using the CVF-FAT interface, it is possible to load a module that handles
+all the low-level disk access that has to do with on-the-fly compression
+and decompression. All other part of FAT filesystem access is still handled
+by the FAT, MSDOS or VFAT or even UMSDOS driver.
+
+CVF access works by redirecting certain low-level routines from the FAT
+driver to a loadable, CVF-format specific module. This module must fake
+a normal FAT filesystem to the FAT driver while doing all the extra stuff
+like compression and decompression silently.
+
+
+2. Restrictions
+------------------------------------------------------------------------------
+
+- BMAP problems
+
+  CVF filesystems cannot do bmap. It's impossible by principle. Thus
+  all actions that require bmap do not work (swapping, writable mmapping).
+  Read-only mmapping works because the FAT driver has a hack for this
+  situation :) Well, with some tricks writable mmapping could work,
+  (proof: they did under old dmsdos), but..... (hint: readpage/writepage
+  interface functions) ...... but the FAT driver has to support them 
+  first without bmap :-)
+
+  We'll see. If someone points me to an application that needs this, I
+  might be persuaded to implement it :). CVF-FAT is already prepared
+  for using readpage.
+  
+- DOSEMU users attention 
+
+  You may have to unmount all CVF partitions before running DOSEMU depending 
+  on your configuration. If DOSEMU is configured to use wholedisk or 
+  partition access (this is often the case to let DOSEMU access 
+  compressed partitions) there's a risk of destroying your compressed 
+  partitions or crashing your system because of confused drivers.
+  
+  Note that it is always safe to redirect the compressed partitions with 
+  lredir or emufs.sys. Refer to the DOSEMU documentation for details.
+
+
+3. Mount options
+------------------------------------------------------------------------------
+
+The CVF-FAT extension currently adds the following options to the FAT
+driver's standard options:
+
+  cvf_format=xxx
+    Forces the driver to use the CVF module "xxx" instead of auto-detection.
+    This is only necessary if the CVF format is not recognized corrrectly
+    because of bugs or incompatibilities in the CVF modules. (It skips
+    the detect_cvf call.) "xxx" may be the text "none" (without the quotes)
+    to inhibit using any of the loaded CVF modules, just in case a CVF
+    module insists on mounting plain FAT filesystems by misunderstanding :)
+
+  cvf_options=yyy
+    Option string passed to the CVF module. I.e. only the "yyy" is passed
+    (without the quotes). The documentation for each CVF module should 
+    explain it since it is interpreted only by the CVF module. Note that 
+    the string must not contain a comma (",") - this would lead to 
+    misinterpretation by the FAT driver, which would recognize the text 
+    after a comma as a FAT driver option and might get confused or print 
+    strange error messages. The documentation for the CVF module should 
+    offer a different seperation symbol, for example the dot ".", which
+    is only valid inside the string "yyy".
+
+
+4. Description of the CVF-FAT interface
+------------------------------------------------------------------------------
+
+Assuming you want to write your own CVF module, you need to write a lot of
+interface funtions. Most of them are covered in the kernel documentation
+you can find on the net, and thus won't be described here. They have been
+marked with "[...]" :-) Take a look at include/linux/fat_cvf.h.
+
+struct cvf_format
+{ int cvf_version;
+  char* cvf_version_text;
+  unsigned long int flags;
+  int (*detect_cvf) (struct super_block*sb);
+  int (*mount_cvf) (struct super_block*sb,char*options);
+  int (*unmount_cvf) (struct super_block*sb);
+  [...]
+  void (*cvf_zero_cluster) (struct inode*inode,int clusternr);
+}
+
+This structure defines the capabilities of a CVF module. It must be filled
+out completely by a CVF module. Consider it as a kind of form that is used
+to introduce the module to the FAT/CVF-FAT driver.
+
+It contains...
+  - cvf_version:
+      A version id which must be uniqe. Choose one.
+  - cvf_version_text:
+      A human readable version string that should be one short word 
+      describing the CVF format the module implements. This text is used
+      for the cvf_format option. This name must also be uniqe.
+  - flags:
+      Bit coded flags, currently only used for a readpage/mmap hack that 
+      provides both mmap and readpage functionality. If CVF_USE_READPAGE
+      is set, mmap is set to generic_file_mmap and readpage is caught
+      and redirected to the cvf_readpage function. If it is not set,
+      readpage is set to generic_readpage and mmap is caught and redirected
+      to cvf_mmap.
+  - detect_cvf:
+      A function that is called to decide whether the filesystem is a CVF of
+      the type the module supports. The detect_cvf function must return 0
+      for "NO, I DON'T KNOW THIS GARBAGE" or anything !=0 for "YES, THIS IS
+      THE KIND OF CVF I SUPPORT". The function must maintain the module
+      usage counters for safety, i.e. do MOD_INC_USE_COUNT at the beginning
+      and MOD_DEC_USE_COUNT at the end. The function *must not* assume that
+      successful recongition would lead to a call of the mount_cvf function
+      later. 
+  - mount_cvf:
+      A function that sets up some values or initializes something additional
+      to what has to be done when a CVF is mounted. This is called at the
+      end of fat_read_super and must return 0 on success. Definitely, this
+      function must increment the module usage counter by MOD_INC_USE_COUNT.
+      This mount_cvf function is also responsible for interpreting a CVF
+      module specific option string (the "yyy" from the FAT mount option
+      "cvf_options=yyy") which cannot contain a comma (use for example the
+      dot "." as option separator symbol).
+  - unmount_cvf:
+      A function that is called when the filesystem is unmounted. Most likely
+      it only frees up some memory and calls MOD_DEC_USE_COUNT. The return
+      value might be ignored (it currently is ignored).
+  - [...]:
+      All other interface functions are "caught" FAT driver functions, i.e.
+      are executed by the FAT driver *instead* of the original FAT driver
+      functions. NULL means use the original FAT driver functions instead.
+      If you really want "no action", write a function that does nothing and 
+      hang it in instead.
+  - cvf_zero_cluster:
+      The cvf_zero_cluster function is called when the fat driver wants to
+      zero out a (new) cluster. This is important for directories (mkdir).
+      If it is NULL, the FAT driver defaults to overwriting the whole
+      cluster with zeros. Note that clusternr is absolute, not relative
+      to the provided inode.
+
+Notes:
+  1. The cvf_bmap function should be ignored. It really should never
+     get called from somewhere. I recommend redirecting it to a panic
+     or fatal error message so bugs show up immediately.
+  2. The cvf_writepage function is ignored. This is because the fat
+     driver doesn't support it. This might change in future. I recommend
+     setting it to NULL (i.e use default).
+
+int register_cvf_format(struct cvf_format*cvf_format);
+  If you have just set up a variable containing the above structure,
+  call this function to introduce your CVF format to the FAT/CVF-FAT
+  driver. This is usually done in init_module. Be sure to check the
+  return value. Zero means success, everything else causes a kernel
+  message printed in the syslog describing the error that occured.
+  Typical errors are:
+    - a module with the same version id is already registered or 
+    - too many CVF formats. Hack fs/fat/cvf.c if you need more.
+
+int unregister_cvf_format(struct cvf_format*cvf_format);
+  This is usually called in cleanup_module. Return value =0 means
+  success. An error only occurs if you try to unregister a CVF format
+  that has not been previously registered. The code uses the version id
+  to distinguish the modules, so be sure to keep it uniqe.
+
+5. CVS Modules
+------------------------------------------------------------------------------
+
+Refer to the dmsdos module (the successor of the dmsdos filesystem) for a
+sample implementation.  It can currently be found at
+
+  ftp://fb9nt.uni-duisburg.de/pub/linux/dmsdos
+
diff --git a/Documentation/filesystems/isofs.txt b/Documentation/filesystems/isofs.txt
new file mode 100644
index 000000000..2f0a4249e
--- /dev/null
+++ b/Documentation/filesystems/isofs.txt
@@ -0,0 +1,28 @@
+Mount options that are the same as for msdos and vfat partitions.
+
+  gid=nnn	All files in the partition will be in group nnn.
+  uid=nnn	All files in the partition will be owned by user id nnn.
+  umask=nnn	The permission mask (see umask(1)) for the partition.
+
+Mount options that are the same as vfat partitions. These are only useful
+when using discs encoded using Microsoft's Joliet extensions.
+  iocharset=name Character set to use for converting from Unicode to
+		ASCII.  Joliet filenames are stored in Unicode format, but
+		Unix for the most part doesn't know how to deal with Unicode.
+		There is also an option of doing UTF8 translations with the
+		utf8 option.
+  utf8          Encode Unicode names in UTF8 format. Default is no.
+
+Mount options that are unique to the isofs filesystem.
+  block=512     Set the block size for the disk to 512 bytes
+  block=1024    Set the block size for the disk to 1024 bytes
+  block=2048    Set the block size for the disk to 2048 bytes
+  check=relaxed Matches filenames with different cases
+  check=strict  Matches only filenames with the exact same case
+  cruft         Try to handle badly formatted CDs.
+  map=off       Do not map non-rockridge filenames to lowercase
+  map=normal    Map rockridge filenames to lowercase
+  mode=xxx      Sets the permissions on files to xxx
+  nojoliet      Ignore Joliet extensions if they are present.
+  norock        Ignore rockridge extensions if they are present.
+  unhide        Show hidden files.
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
new file mode 100644
index 000000000..504408e52
--- /dev/null
+++ b/Documentation/filesystems/ntfs.txt
@@ -0,0 +1,30 @@
+NTFS Overview
+=============
+
+To mount an NTFS volume, use the filesystem type 'ntfs'. The driver
+currently works only in read-only mode, with no fault-tolerance
+supported.  If you enable the experimental write support, make sure
+you can recover from a complete loss of data. For ftdisk support,
+limit success was reported with volume sets on top of the md driver,
+although mirror and stripe sets should work as well - if the md
+driver can be talked into using the same lay-out as Windows NT.
+
+The ntfs driver supports the following mount options:
+iocharset=name      Character set to use when returning file names.
+                    Unlike VFAT, NTFS suppresses names that contain
+		    unconvertible characters
+utf8=<bool>	    Use UTF-8 for converting file names
+uni_xlate=<bool>,2  Use the VFAT-style encoding for file names outside
+		    the current character set. A boolean value will
+		    enable the feature, a value of 2 will enable the
+		    encoding as documented in vfat.txt:
+		    ':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12),
+uid=
+gid=
+umask=              These options work as documented in mount(8).
+		    By default, the files are owned by root and
+		    not readable by somebody else.
+posix=<bool>	    If enabled, the file system distinguishes between
+		    upper and lower case. The 8.3 alias names are presented
+		    as hard links instead of being suppressed.
+
diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt
index 04eb2e586..5fc080576 100644
--- a/Documentation/filesystems/smbfs.txt
+++ b/Documentation/filesystems/smbfs.txt
@@ -1,27 +1,20 @@
 Smbfs is a filesystem that implements the SMB protocol, which is the
 protocol used by Windows for Workgroups, Windows 95 and Windows NT.
-Smbfs was inspired by samba, the program written by Andrew Tridgell
+Smbfs was inspired by Samba, the program written by Andrew Tridgell
 that turns any unix host into a file server for DOS or Windows clients.
 See ftp://nimbus.anu.edu.au/pub/tridge/samba/ for this interesting
 program suite and much more information on SMB, NetBIOS over TCP/IP,
 and explanations for concepts like netbios name or share.
 
-To use smbfs, you need to install the Samba package (Samba-1.9.17p1 or
-later), and you need the special mount program from the smbfs package
-(smbfs-2.1.0 or later), found on
+To use smbfs, you must first install the Samba package (Samba-1.9.18p1 or
+later). This package includes the special smbmount utility needed to mount
+smbfs volumes. Refer to the smbmount(8) and smbmnt(8) manpages for the
+details regarding smbfs mounts.
 
-	ftp://ftp.gwdg.de/pub/linux/misc/smbfs/dontuse
-
-After downloading the smbfs package, apply the patch to the smbclient
-program and recompile.  Smbfs can then be mounted from the smbclient
-command line, as for example:
-
-	smb: \>mount /mnt/tmp -f 755
-
-For convenience, you may wish to package the command in a script like this:
-
-#!/bin/sh
-echo "mount /mnt/tmp -f 755" | smbclient //server/c$ -U administrator%
+The smbmount utility reads the Samba smb.conf config file for some of its
+options, and at least one of these is important for smbfs operation. You
+should enable the TCP_NODELAY socket option, or else directory listings
+will be dramatically slower (under Win NT at least).
 
 Mount-Time Options
 Windows 95 has several bugs that affect SMB operations, and smbfs includes
@@ -37,11 +30,12 @@ to the file mode argument of the mount command for the Win 95 servers.
 Option                  Value  Effect
 Identify Win 95 Server    1    Enables bug fixes
 Use Core Attributes       2    Speeds up directory scans, only mtime
+Use Dir Attributes        4    Alternate way to get file attributes
 
 To apply the options, sum the values and prepend it to the file mode. For
-example, to use both options with file mode 755, you would prepend 3 to 755:
+example, to use options 1 and 2 with file mode 755, you would specify 3755:
 
-	cnt>mount /mnt/tmp -f 3755
+	mount /mnt/tmp -f 3755
 
 Smbfs will print a message at mount time confirming the selected options.
 Note that _only_ Windows 95 servers require special treatment; using the
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index 050a4306a..61f44a87c 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -43,6 +43,10 @@ nonumtail=<bool> -- When creating 8.3 aliases, normally the alias will
                  be the short alias instead of 'longfi~1.txt'. 
                   
 quiet         -- Stops printing certain warning messages.
+check=s|r|n   -- Case sensitivity checking setting.
+                 s: strict, case sensitive
+                 r: relaxed, case insensitive
+                 n: normal, default setting, currently case insensitive
 
 <bool>: 0,1,yes,no,true,false
 
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index e4922c3b9..0644c2e2f 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -8,7 +8,7 @@ I've learned while writing lofs...
 The VFS relatively simple, but it is nice not to have to browse through
 pages of code to determine what is expected when writing a filesystem.
 Hopefully this helps anyone attempting such a feat, as well as clearing up
-a few important points/dependancies.
+a few important points/dependencies.
 
 
 register_filesystem (struct file_system_type *fstype)