update( Documentation -> vfs.txt -> file_system_type );

diff -r -u linux-2.6.13-rc1.UNTOUCHED/Documentation/filesystems/vfs.txt linux-2.6.13-rc1/Documentation/filesystems/vfs.txt
@@ -126,46 +126,53 @@
 struct file_system_type                                               <section>
 =======================
 
-This describes the filesystem. As of kernel 2.1.99, the following
+This describes the filesystem. As of kernel 2.6.13, the following
 members are defined:
 
 struct file_system_type {
-       const char *name;
-       int fs_flags;
-       struct super_block *(*read_super) (struct super_block *, void *, int);
-       struct file_system_type * next;
-};
-
-  name: the name of the filesystem type, such as "ext2", "iso9660",
-       "msdos" and so on
-
-  fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
-
-  read_super: the method to call when a new instance of this
-       filesystem should be mounted
-
-  next: for internal VFS use: you should initialise this to NULL
-
-The read_super() method has the following arguments:
-
-  struct super_block *sb: the superblock structure. This is partially
-       initialised by the VFS and the rest must be initialised by the
-       read_super() method
-
-  void *data: arbitrary mount options, usually comes as an ASCII
-       string
+        const char *name;
+        int fs_flags;
+        struct super_block *(*get_sb)
+               (struct file_system_type *, int, const char *, void *);
+        void (*kill_sb) (struct super_block *);
+        struct module *owner;
+        struct file_system_type * next;
+        struct list_head fs_supers;
+       };
+
+  name: The name of the filesystem type, such as "ext2", "iso9660",
+       "msdos" and so on.
+
+  fs_flags: A combination of: FS_REQUIRES_DEV, FS_BINARY_MOUNTDATA,
+       FS_REVAL_DOT, FS_ODD_RENAME (deprecated). See include/linux/fs.h.
+
+  get_sb: The function responsible for returning the super_block structure
+       containing the filesystems blocksize, it's super block,
+       super operations struct s_op (which is the most interesting field
+       filled by this method and a pointer to struct super_operations
+       which describes the next level of the filesystem implementation),
+       the magic byte and max filesize and the like.
+       It is called when a new instance of this filesystem is mounted and
+       replaces the read_super function of former kernels (see porting).
+       As an example of what to do here please look at one of the default
+       functions in the kernel code named 'get_sb_nodev'.
+       The get_sb_nodev functions last parameter is a pointer to a function
+       which would act like the former read_super function just mentioned.
+       The data parameter contains arbitrary mount options passed by the
+       unix mount program, it usually comes as an ASCII string but can
+       be set to come as binary (now please don't ask me where I saw this
+       flag, look at the source, Mr. Skywalker ;-).
+       Return value: New super block on success, ERR_PTR if failed.
+
+  kill_sb: the function which gets called when the sb needs to be destroyed.
+       One generic function for this is 'kill_anon_super', look there for
+       more inspiration.
 
-  int silent: whether or not to be silent on error
+  owner: This is usually set to the macro 'THIS_MODULE'.
 
-The read_super() method must determine if the block device specified
-in the superblock contains a filesystem of the type the method
-supports. On success the method returns the superblock pointer, on
-failure it returns NULL.
+  next: Managed by the kernel. Please leave it as NULL.
 
-The most interesting member of the superblock structure that the
-read_super() method fills in is the "s_op" field. This is a pointer to
-a "struct super_operations" which describes the next level of the
-filesystem implementation.
+  fs_supers: Managed by the kernel. Please leave it as NULL.
 
 
 struct super_operations                                               <section>