o Merge with Linux 2.1.99.

 o Fix ancient bug in the ELF loader making ldd crash.
 o Fix ancient bug in the keyboard code for SGI, SNI and Jazz.

9 files changed, 91 insertions, 76 deletions

diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 72903619e..679904d0b 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -2,12 +2,19 @@
 	- this file (info on some of the filesystems supported by linux).
 affs.txt
 	- info and mount options for the Amiga Fast File System.
+coda.txt
+	- description of the CODA filesystem.
+fat_cvf.txt
+	- Description of the Compressed Volume Files extension to the FAT
+	  filesystem
 hpfs.txt
 	- info and mount options for the OS/2 HPFS.
 isofs.txt
 	- info and mount options for the ISO9660 (CDROM) filesystem.
 ncpfs.txt
 	- info on Novell Netware(tm) filesystem using NCP protocol.
+ntfs.txt
+	- info and mount options for the NTFS filesystem (Win NT).
 romfs.txt
 	- Description of the ROMFS filesystem.
 smbfs.txt
@@ -18,3 +25,5 @@ umsdos.txt
 	- info on the umsdos extensions to the msdos filesystem.
 vfat.txt
 	- info on using the VFAT filesystem used in Win NT and Win 95
+vfs.txt
+	- Overview of the Virtual File System
diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt
index 4c5d7fa7a..85d5a58b1 100644
--- a/Documentation/filesystems/affs.txt
+++ b/Documentation/filesystems/affs.txt
@@ -120,8 +120,8 @@ Symbolic links
 Although the Amiga and Linux file systems resemble each other, there
 are some, not always subtle, differences. One of them becomes apparent
 with symbolic links. While Linux has a file system with exactly one
-root directory, the Amiga has a seperate root directory for each
-file system (i. e. partition, floppy disk, ...). With the Amiga,
+root directory, the Amiga has a separate root directory for each
+file system (e.g. partition, floppy disk, ...). With the Amiga,
 these entities are called "volumes". They have symbolic names which
 can be used to access them. Thus, symbolic links can point to a
 different volume. AFFS turns the volume name into a directory name
@@ -156,7 +156,7 @@ fs/affs/Changes.
 
 Filenames are truncated to 30 characters without warning (this
 can be changed by setting the compile-time option AFFS_NO_TRUNCATE
-ina include/linux/amigaffs.h).
+in include/linux/amigaffs.h).
 
 Case is ignored by the affs in filename matching, but Linux shells
 do care about the case. Example (with /mnt being an affs mounted fs):
diff --git a/Documentation/filesystems/coda.txt b/Documentation/filesystems/coda.txt
index f049c02a6..0c88ce6dc 100644
--- a/Documentation/filesystems/coda.txt
+++ b/Documentation/filesystems/coda.txt
@@ -28,7 +28,7 @@ kernel support.
 
   This document describes the communication between Venus and kernel
   level file system code needed for the operation of the Coda filesys-
-  tem.  This version document is meant to describe the current interface
+  tem.  This document version is meant to describe the current interface
   (version 1.0) as well as improvements we envisage.
   ______________________________________________________________________
 
@@ -161,7 +161,7 @@ kernel support.
   client cache and makes remote procedure calls to Coda file servers and
   related servers (such as authentication servers) to service these
   requests it receives from the operating system.  When Venus has
-  serviced a request it replies to the operating system with appropiate
+  serviced a request it replies to the operating system with appropriate
   return codes, and other data related to the request.  Optionally the
   kernel support for Coda may maintain a minicache of recently processed
   requests to limit the number of interactions with Venus.  Venus
@@ -218,10 +218,10 @@ kernel support.
   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 objects.  The Coda FS layer services
-  such VFS requests in by invoking on or more well defined services
+  such VFS requests by invoking one 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
-  finishes with a reply to the kernels VFS. Finally the VFS layer
+  finishes with a reply to the kernel's VFS. Finally the VFS layer
   returns to the process.
 
   As a result of this design a basic interface exposed by the FS driver
@@ -277,7 +277,7 @@ kernel support.
   FS Driver in kernel memory on behalf of P and copied to user memory in
   Venus.
 
-  The FS Driver while servicing P makes upcall's to Venus.  Such an
+  The FS Driver while servicing P makes upcalls to Venus.  Such an
   upcall is dispatched to Venus by creating a message structure.  The
   structure contains the identification of P, the message sequence
   number, the size of the request and a pointer to the data in kernel
@@ -289,7 +289,7 @@ kernel support.
   synchronization objects.  In the upcall routine the message structure
   is filled in, flags are set to 0, and it is placed on the _p_e_n_d_i_n_g
   queue.  The routine calling upcall is responsible for allocating the
-  data buffer; it's structure will be described in the next section.
+  data buffer; its structure will be described in the next section.
 
   A facility must exist to notify Venus that the message has been
   created, and implemented using available synchronization objects in
@@ -323,15 +323,15 @@ kernel support.
 
   +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 cache eviction or replacement) and when finishes
+     (usually a cache eviction or replacement) and when it finishes
      sendmsg_to_kernel returns.
 
   Now P awakes and continues processing upcall.  There are some
-  subtleties to take account off. First P will determine if it was woken
+  subtleties to take account of. First P will determine if it was woken
   up in upcall by a signal from some other source (for example an
   attempt to terminate P) or as is normally the case by Venus in its
   sendmsg_to_kernel call.  In the normal case, the upcall routine will
-  deallocate message structure and return.  The FS routine can proceed
+  deallocate the message structure and return.  The FS routine can proceed
   with its processing.
 
 
@@ -344,7 +344,7 @@ kernel support.
 
   In case P is woken up by a signal and not by Venus, it will first look
   at the flags field.  If the message is not yet READ, the process P can
-  handle it's signal without notifying Venus.  If Venus has READ, and
+  handle its signal without notifying Venus.  If Venus has READ, and
   the request should not be processed, P can send Venus a signal message
   to indicate that it should disregard the previous message.  Such
   signals are put in the queue at the head, and read first by Venus.  If
@@ -407,7 +407,7 @@ kernel support.
   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
-  which we will discuss.   The unique field labels the inputArg with
+  which we will discuss.   The unique field labels the inputArg with a
   unique number which will identify the message uniquely.  A process and
   process group id are passed.  Finally the credentials of the caller
   are included.
@@ -421,9 +421,9 @@ kernel support.
   44..11..  DDaattaa ssttrruuccttuurreess sshhaarreedd bbyy tthhee kkeerrnneell aanndd VVeennuuss
 
 
-  The CodaCred structure defines a variety of user and group id's as
+  The CodaCred structure defines a variety of user and group ids 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
+  unsigned integers.  It also defines group membership in an array.  On
   Unix the CodaCred has proven sufficient to implement good security
   semantics for Coda but the structure may have to undergo modification
   for the Windows environment when these mature.
@@ -462,7 +462,7 @@ kernel support.
   to be prefixed to identify the Coda cell; this will probably take the
   form of a Ipv6 size IP address naming the Coda cell through DNS.
 
-  The next important structure shared between Venus and the kernel are
+  The next important structure shared between Venus and the kernel is
   the attributes of the file.  The following structure is used to
   exchange information.  It has room for future extensions such as
   support for device files (currently not present in Coda).
@@ -514,7 +514,7 @@ kernel support.
 
   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
+  ficticious file /coda/.CONTROL.  The pioctl call opens this file, gets
   a file handle and makes the ioctl call. Finally it closes the file.
 
   The kernel involvement in this is limited to providing the facility to
@@ -614,7 +614,7 @@ kernel support.
   The name of the object is an 8 bit character string of maximum length
   CFS_MAXNAMLEN, currently set to 256 (including a 0 terminator.)
 
-  It is extremely important to realize that Venus bitwise or's the field
+  It is extremely important to realize that Venus bitwise ors the field
   cfs_lookup.vtype with CFS_NOCACHE to indicate that the object should
   not be put in the kernel name cache.
 
@@ -650,11 +650,11 @@ kernel support.
   DDeessccrriippttiioonn This call returns the attributes of the file identified by
   fid.
 
-  EErrrroorrss Errors can occur if the object with fid does not exist, are
+  EErrrroorrss Errors can occur if the object with fid does not exist, is
   unaccessible or if the caller does not have permission to fetch
   attributes.
 
-  NNoottee Many kernel FS drivers (Linux, NT and Windows 95 need to acquire
+  NNoottee Many kernel FS drivers (Linux, NT and Windows 95) need to acquire
   the attributes as well as the Fid for the instantiation of an internal
   "inode" or "FileHandle".  A significant improvement in performance on
   such systems could be made by combining the _l_o_o_k_u_p and _g_e_t_a_t_t_r calls
@@ -689,7 +689,7 @@ kernel support.
   in BSD style.  Attributes not to be changed are set to -1, apart from
   vtype which is set to VNON. Other are set to the value to be assigned.
   The only attributes which the FS driver may request to change are the
-  mode, ownner, groupid, atime, mtime and ctime.  The return value
+  mode, owner, groupid, atime, mtime and ctime.  The return value
   indicates success or failure.
 
   EErrrroorrss A variety of errors can occur.  The object may not exist, may
@@ -719,7 +719,7 @@ kernel support.
   DDeessccrriippttiioonn Verify if access to the object identified by VFid for
   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
+  ACLs to enforce protection and that ultimately the servers, not the
   clients enforce the security of the system.  The result of this call
   will depend on wether a _t_o_k_e_n is held by the user.
 
@@ -851,7 +851,7 @@ kernel support.
 
   DDeessccrriippttiioonn This call creates a link to the sourceFid in the directory
   identified by destFid with name tname.  The source must reside in the
-  targets parent, i.e. the source must be have parent destFid, i.e. Coda
+  target's parent, i.e. the source must be have parent destFid, i.e. Coda
   does not support cross directory hard links.  Only the return value is
   relevant.  It indicates success or the type of failure.
 
@@ -1015,7 +1015,7 @@ kernel support.
   EErrrroorrss
 
   NNOOTTEE Currently the cfs_open_out structure is not properly adapted to
-  deal with the windows case.  It might be best to implement two
+  deal with the Windows case.  It might be best to implement two
   upcalls, one to open aiming at a container file name, the other at a
   container file inode.
 
@@ -1051,7 +1051,7 @@ kernel support.
   fetching the data in Venus vproc_vfscalls.  This seems silly.  If a
   file is being closed, the data in the container file is to be the new
   data.  Here again the execp flag might be in play to create confusion:
-  presently Venus might think a file can be flushed from the cache when
+  currently Venus might think a file can be flushed from the cache when
   it is still memory mapped.  This needs to be understood.
 
   0wpage
@@ -1059,7 +1059,7 @@ kernel support.
   44..1177..  iiooccttll
 
 
-  SSuummmmaarryy Do an ioctl on a file. This includes the piocl interface.
+  SSuummmmaarryy Do an ioctl on a file. This includes the pioctl interface.
 
   AArrgguummeennttss
 
@@ -1091,7 +1091,7 @@ kernel support.
   EErrrroorrss
 
   NNOOTTEE Another bogus parameter.  flags is not used.  What is the
-  business about PREFETCHING in the Venus' code?
+  business about PREFETCHING in the Venus code?
 
 
   0wpage
@@ -1154,8 +1154,8 @@ kernel support.
 
 
   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.
+  read at most count bytes.  Returns the data in data and returns
+  the size in size.
 
   EErrrroorrss
 
@@ -1196,7 +1196,7 @@ kernel support.
 
   NNOOTTEE This operation is not used.  However, it is extremely useful
   since it can be used to deal with read/write memory mapped files.
-  These can be "pinned" in the Venus cache using vget and release with
+  These can be "pinned" in the Venus cache using vget and released with
   inactive.
 
   0wpage
@@ -1219,8 +1219,8 @@ kernel support.
      oouutt
         none
 
-  DDeessccrriippttiioonn  Ask Venus to update RVM attributes of object VFid. This
-  should be called as  part of kernel level fsync type calls.  The
+  DDeessccrriippttiioonn Ask Venus to update RVM attributes of object VFid. This
+  should be called as part of kernel level fsync type calls.  The
   result indicates if the synching was successful.
 
   EErrrroorrss
@@ -1452,7 +1452,7 @@ kernel support.
   4. the cnode of the object
 
   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
+  desired object from the cache, by passing its name, directory and the
   CodaCred's of the caller.  The cache will return the cnode or indicate
   that it cannot be found.  The Coda FS Driver must be careful to
   invalidate cache entries when it modifies or removes objects.
@@ -1496,7 +1496,7 @@ kernel support.
 
 
   DDeessccrriippttiioonn Remove all entries in the cache carrying the Cred.  This
-  call is issued when tokes for a user expire or are flushed.
+  call is issued when tokens for a user expire or are flushed.
 
 
   55..44..  ZZAAPPFFIILLEE
@@ -1567,7 +1567,7 @@ kernel support.
 
 
   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
+  vnode), purge its children from the namecache and remove the file from the
   namecache.
 
 
@@ -1589,7 +1589,7 @@ kernel support.
   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
-  when the reference count on those fids are not zero.
+  when the reference counts on those fids are not zero.
 
   0wpage
 
@@ -1629,7 +1629,7 @@ kernel support.
   66..11..  RReeqquuiirreemmeennttss
 
 
-  The following requirements should be accomodated:
+  The following requirements should be accommodated:
 
   1. The message queueus should have open and close routines.  On Unix
      the opening of the character devices are such routines.
@@ -1659,7 +1659,7 @@ kernel support.
 
   6. All memory held by cnodes can be freed without relying on upcalls.
 
-  7. Unmounting the file system can be done without relying on upcalss.
+  7. Unmounting the file system can be done without relying on upcalls.
 
   8. Mounting the Coda filesystem should fail gracefully if Venus cannot
      get the rootfid or the attributes of the rootfid.  The latter is
diff --git a/Documentation/filesystems/fat_cvf.txt b/Documentation/filesystems/fat_cvf.txt
index 9e7062e13..ef598932c 100644
--- a/Documentation/filesystems/fat_cvf.txt
+++ b/Documentation/filesystems/fat_cvf.txt
@@ -34,7 +34,7 @@ like compression and decompression silently.
 
 - BMAP problems
 
-  CVF filesystems cannot do bmap. It's impossible by principle. Thus
+  CVF filesystems cannot do bmap. It's impossible in 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,
@@ -66,7 +66,7 @@ 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
+    This is only necessary if the CVF format is not recognized correctly
     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
@@ -80,7 +80,7 @@ driver's standard options:
     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
+    offer a different separation symbol, for example the dot ".", which
     is only valid inside the string "yyy".
 
 
@@ -109,11 +109,11 @@ to introduce the module to the FAT/CVF-FAT driver.
 
 It contains...
   - cvf_version:
-      A version id which must be uniqe. Choose one.
+      A version id which must be unique. 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.
+      for the cvf_format option. This name must also be unique.
   - flags:
       Bit coded flags, currently only used for a readpage/mmap hack that 
       provides both mmap and readpage functionality. If CVF_USE_READPAGE
@@ -178,7 +178,7 @@ 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.
+  to distinguish the modules, so be sure to keep it unique.
 
 5. CVS Modules
 ------------------------------------------------------------------------------
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 504408e52..d9789eadb 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -5,9 +5,9 @@ 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,
+limited 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.
+driver can be talked into using the same layout as Windows NT.
 
 The ntfs driver supports the following mount options:
 iocharset=name      Character set to use when returning file names.
diff --git a/Documentation/filesystems/romfs.txt b/Documentation/filesystems/romfs.txt
index 32a14e68b..7df713201 100644
--- a/Documentation/filesystems/romfs.txt
+++ b/Documentation/filesystems/romfs.txt
@@ -22,7 +22,7 @@ genromfs.  It is available via anonymous ftp on sunsite.unc.edu and
 its mirrors, in the /pub/Linux/system/recovery/ directory.
 
 As the name suggests, romfs could be also used (space-efficiently) on
-various read-only medias, like (E)EPROM disks if someone will have the
+various read-only media, like (E)EPROM disks if someone will have the
 motivation.. :)
 
 However, the main purpose of romfs is to have a very small kernel,
@@ -79,7 +79,7 @@ The first eight bytes identify the filesystem, even for the casual
 inspector.  After that, in the 3rd longword, it contains the number of
 bytes accessible from the start of this filesystem.  The 4th longword
 is the checksum of the first 512 bytes (or the number of bytes
-accessible, whichever is smallest).  The applied algorithm is the same
+accessible, whichever is smaller).  The applied algorithm is the same
 as in the AFFS filesystem, namely a simple sum of the longwords
 (assuming bigendian quantities again).  For details, please consult
 the source.  This algorithm was chosen because although it's not quite
diff --git a/Documentation/filesystems/umsdos.txt b/Documentation/filesystems/umsdos.txt
index 320dac6ca..9dda08913 100644
--- a/Documentation/filesystems/umsdos.txt
+++ b/Documentation/filesystems/umsdos.txt
@@ -1,20 +1,26 @@
+Firstly, let me say that UMSDOS is going through some major code changes,
+and has some KNOWN BUGS (and quite a few unknown :-). Please read
+fs/umsdos/README-WIP.txt for more information on current status. Thanks.
+
+----------------------------------------------------------------------------
 Very short explanation for the impatient!!!
 
 Umsdos is a file system driver that run on top the MSDOS fs driver.
 It is written by Jacques Gelinas (jacques@solucorp.qc.ca)
+and is currently maintained by Matija Nalis (mnalis@jagor.srce.hr)
 
 Umsdos is not a file system per se, but a twist to make a boring
 one into a useful one.
 
 It gives you:
 
-	long file name
-	Permissions and owner
+	long file names
+	Permissions and owners
 	Links
-	Special files (devices, pipe...)
-	All is need to be a linux root fs.
+	Special files (devices, pipes...)
+	All that is needed to be a linux root fs.
 
-There is plenty of documentation on it in the source. A formated document
+There is plenty of documentation on it in the source. A formatted document
 made from those comments is available from
 sunsite.unc.edu:/pub/Linux/system/Filesystems/umsdos.
 
@@ -26,21 +32,21 @@ mount -t umsdos /dev/hda3 /mnt
          ^
 ---------|
 
-All option are passed to the msdos drivers. Option like uid,gid etc are
+All options are passed to the msdos drivers. Option like uid,gid etc are
 given to msdos.
 
 The default behavior of Umsdos is to do the same thing as the msdos driver
 mostly passing commands to it without much processing. Again, this is
 the default. After doing the mount on a DOS partition, nothing special
-happen. This is why all mount options are passed to the Msdos fs driver.
+happens. This is why all mount options are passed to the msdos fs driver.
 
-Umsdos use a special DOS file --linux-.--- to store the information
+Umsdos uses a special DOS file --linux-.--- to store the information
 which can't be handle by the normal MsDOS file system. This is the trick.
 
 --linux-.--- is optional. There is one per directory.
 
 **** If --linux-.--- is missing, then Umsdos process the directory the
-     same way the msdos driver do. Short file name, no goodies, default
+     same way the msdos driver does. Short file names, no goodies, default
      owner and permissions. So each directory may have or not this
      --linux-.---
 
@@ -53,7 +59,7 @@ Now, how to get those --linux-.---.
 	$5 per directory. Add any applicable taxes.
 \end joke_section
 
-A utility umssync creates those. The kernel maintain them. It is available
+A utility umssync creates those. The kernel maintains them. It is available
 from the same directory above (sunsite) in the file umsdos_progs-0.7.tar.gz.
 A compiled version is available in umsdos_progs-0.7.bin.tar.gz.
 
@@ -63,20 +69,20 @@ umssync .
 
 This will promote this directory (a recursive option is available) to full
 umsdos capabilities (long name ...). A ls -l before and after won't show
-much difference however. The file which were there are still there. But now
+much difference however. The files which were there are still there. But now
 you can do all this:
 
 	chmod 644 *
-	chown you.your_groupe *
+	chown you.your_group *
 	ls >THIS_IS.A.VERY.LONG.NAME
 	ln -s toto tata
 	ls -l
 
-Once a directory is promoted, all subdirectory created will inherit that
+Once a directory is promoted, all subdirectories created will inherit that
 promotion.
 
-What happen if you boot DOS and create files in those promoted directories ?
-Umsdos won't notice new files, but will signal removed file (it won't crash).
+What happens if you boot DOS and create files in those promoted directories ?
+Umsdos won't notice new files, but will signal removed files (it won't crash).
 Using umssync in /etc/rc will make sure the DOS directory is in sync with
 the --linux-.---.
 
@@ -89,8 +95,8 @@ after the "mount -a":
 	(You put one for each umsdos mount point in the fstab)
 
 This will insure nice operation. A umsdos.fsck is in the making,
-so you will be allowed to managed umsdos partition in the same way
-other filesystem are, using the generic fsck front end.
+so you will be allowed to manage umsdos partitions in the same way
+other filesystems are, using the generic fsck front end.
 
 Hope this helps!
 
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index 61f44a87c..1a0da9d40 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -71,7 +71,7 @@ POSSIBLE PROBLEMS
 * vfat_valid_longname does not properly checked reserved names.
 * When a volume name is the same as a directory name in the root
   directory of the filesystem, the directory name sometimes shows
-  up empty an empty file.
+  up as an empty file.
 * autoconv option does not work correctly.
 
 BUG REPORTS
@@ -103,7 +103,7 @@ but it appears to be so.
 The extended FAT file system is almost identical to the FAT
 file system used in DOS versions up to and including 6.223410239847
 :-).  The significant change has been the addition of long file names.
-Theses names support up to 255 characters including spaces and lower
+These names support up to 255 characters including spaces and lower
 case characters as opposed to the traditional 8.3 short names.
 
 Here is the description of the traditional FAT entry in the current
@@ -142,7 +142,7 @@ directory entries for any files with extended names.  (Any name which
 legally fits within the old 8.3 encoding scheme does not have extra
 entries.)  I call these extra entries slots.  Basically, a slot is a
 specially formatted directory entry which holds up to 13 characters of
-a files extended name.  Think of slots as additional labeling for the
+a file's extended name.  Think of slots as additional labeling for the
 directory entry of the file to which they correspond.  Microsoft
 prefers to refer to the 8.3 entry for a file as its alias and the
 extended slot directory entries as the file name. 
@@ -163,7 +163,7 @@ The C structure for a slot directory entry follows:
 If the layout of the slots looks a little odd, it's only
 because of Microsoft's efforts to maintain compatibility with old
 software.  The slots must be disguised to prevent old software from
-panicing.  To this end, a number of measures are taken:
+panicking.  To this end, a number of measures are taken:
 
         1) The attribute byte for a slot directory entry is always set
            to 0x0f.  This corresponds to an old directory entry with
@@ -206,9 +206,9 @@ the following:
                         sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + name[i]
                 }
 
-	3) If there is in the final slot, a Unicode NULL (0x0000) is stored
-           after the final character.  After that, all unused characters in
-           the final slot are set to Unicode 0xFFFF.
+	3) If there is free space in the final slot, a Unicode NULL (0x0000) 
+	   is stored after the final character.  After that, all unused 
+	   characters in the final slot are set to Unicode 0xFFFF.
 
 Finally, note that the extended name is stored in Unicode.  Each Unicode
 character takes two bytes.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 0644c2e2f..7f75f4770 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -5,7 +5,7 @@ A Brief Overview of the Virtual File System
 Noone else seems to be writing this, so here's a quick description of what
 I've learned while writing lofs...
 
-The VFS relatively simple, but it is nice not to have to browse through
+The VFS is 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/dependencies.
@@ -133,9 +133,9 @@ struct inode_operations
 
 	int (*follow_link) (struct inode *,struct inode *,int,int,struct inode **);
 	[optional]
-		The follow_link function is only nescessary if a filesystem uses a really
+		The follow_link function is only necessary if a filesystem uses a really
 		twisted form of symbolic links - namely if the symbolic link comes from a
-		foriegn filesystem that makes no sense....
+		foreign filesystem that makes no sense....
 		I threw this one out - too much redundant code!
 
 	int (*readpage) (struct inode *, struct page *);	[optional]