[RFC][PATCH] VFS: update documentation (take #2)
Hi,
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks to Carsten Otte for the description on get_xip_page().
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
vfs.txt | 382
1 file changed, 291 insertions(+), 91 deletions(-)
Index: 2.6-mm/Documentation/filesystems/vfs.txt
===
--- 2.6-mm.orig/Documentation/filesystems/vfs.txt
+++ 2.6-mm/Documentation/filesystems/vfs.txt
@@ -1,10 +1,9 @@
-/* -*- auto-fill -*- */
Overview of the Virtual File System
- Richard Gooch [EMAIL PROTECTED]
+ Original author: Richard Gooch [EMAIL PROTECTED]
- 5-JUL-1999
+ Last updated on August 24, 2005
Conventions used in this document section
@@ -15,9 +14,6 @@ right-hand side of the section title. Ea
subsection at the right-hand side. These strings are meant to make
it easier to search through the document.
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
What is it? section
===
@@ -26,7 +22,7 @@ The Virtual File System (otherwise known
Switch) is the software layer in the kernel that provides the
filesystem interface to userspace programs. It also provides an
abstraction within the kernel which allows different filesystem
-implementations to co-exist.
+implementations to coexist.
A Quick Look At How It Works section
@@ -77,7 +73,7 @@ back to userspace.
Opening a file requires another operation: allocation of a file
structure (this is the kernel-side implementation of file
-descriptors). The freshly allocated file structure is initialised with
+descriptors). The freshly allocated file structure is initialized with
a pointer to the dentry and a set of file operation member functions.
These are taken from the inode data. The open() file method is then
called so the specific filesystem implementation can do it's work. You
@@ -126,14 +122,18 @@ It's now time to look at things in more
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;
+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,
@@ -141,51 +141,96 @@ struct file_system_type {
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
+ get_sb: 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
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialize this to NULL
-The read_super() method has the following arguments:
+ next: for internal VFS use: you should initialize this to NULL
+
+The get_sb() 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
+ initialized by the VFS and the rest must be initialized by the
+ get_sb() method
+
+ int flags: mount flags
+
+ const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
-The read_super() method must determine if the block device specified
+The get_sb() 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.
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
+get_sb() 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.
+Usually, a filesystem uses generic one of the generic
Re: [RFC][PATCH] VFS: update documentation (take #2)
on den 24.08.2005 Klokka 21:36 (+0300) skreiv Pekka Enberg:
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;
+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,
@@ -141,51 +141,96 @@ struct file_system_type {
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
+ get_sb: 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
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialize this to NULL
owner should be set to THIS_MODULE in most cases...
Cheers,
Trond
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] VFS: update documentation (take #2)
Hi,
This is my second go at giving you my comments. The first time the email
got lost due to a connection crash. )-: Anyway, its great to see this
updated!
On Wed, 24 Aug 2005, Pekka Enberg wrote:
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks to Carsten Otte for the description on get_xip_page().
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
vfs.txt | 382
1 file changed, 291 insertions(+), 91 deletions(-)
Index: 2.6-mm/Documentation/filesystems/vfs.txt
===
--- 2.6-mm.orig/Documentation/filesystems/vfs.txt
+++ 2.6-mm/Documentation/filesystems/vfs.txt
@@ -1,10 +1,9 @@
-/* -*- auto-fill -*-
*/
Overview of the Virtual File System
- Richard Gooch [EMAIL PROTECTED]
+ Original author: Richard Gooch [EMAIL PROTECTED]
- 5-JUL-1999
+ Last updated on August 24, 2005
Conventions used in this document
section
@@ -15,9 +14,6 @@ right-hand side of the section title. Ea
subsection at the right-hand side. These strings are meant to make
it easier to search through the document.
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
What is it?
section
===
@@ -26,7 +22,7 @@ The Virtual File System (otherwise known
Switch) is the software layer in the kernel that provides the
filesystem interface to userspace programs. It also provides an
abstraction within the kernel which allows different filesystem
-implementations to co-exist.
+implementations to coexist.
A Quick Look At How It Works
section
@@ -77,7 +73,7 @@ back to userspace.
Opening a file requires another operation: allocation of a file
structure (this is the kernel-side implementation of file
-descriptors). The freshly allocated file structure is initialised with
+descriptors). The freshly allocated file structure is initialized with
a pointer to the dentry and a set of file operation member functions.
These are taken from the inode data. The open() file method is then
called so the specific filesystem implementation can do it's work. You
@@ -126,14 +122,18 @@ It's now time to look at things in more
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;
+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,
@@ -141,51 +141,96 @@ struct file_system_type {
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
+ get_sb: 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
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialize this to NULL
-The read_super() method has the following arguments:
+ next: for internal VFS use: you should initialize this to NULL
+
+The get_sb() 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
+ initialized by the VFS and the rest must be initialized by the
+ get_sb() method
+
+ int flags: mount flags
+
+ const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
-The read_super() method must determine if the block device specified
+The get_sb() 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.
The most interesting member of the superblock
Re: [RFC][PATCH] VFS: update documentation
On 8/21/05, Pekka Enberg [EMAIL PROTECTED] wrote: This patch updates the out-of-date Documentation/filesystems/vfs.txt. As I am a novice on the VFS, I would much appreciate any comments and help on this. Cool, thanks for updating it :) + get_xip_page: called by the VM to translate a block number to a page. + This is used by filesystems that want to implement execute-in-place + (XIP). A little more would be helpful, like: get_xip_page: called by the VM to translate a block number to a page. The page is valid until the corresponding filesystem is unmounted. Filesystems that want to use execute-in-place (XIP) need to implement it. An example implementation can be found in fs/ext2/xip.c cheers, Carsten - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] VFS: update documentation
Hi!
This patch updates the out-of-date Documentation/filesystems/vfs.txt.
As I am a novice on the VFS, I would much appreciate any comments and
help on this.
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
vfs.txt | 314 +---
1 files changed, 241 insertions(+), 73 deletions(-)
Index: 2.6-mm/Documentation/filesystems/vfs.txt
===
--- 2.6-mm.orig/Documentation/filesystems/vfs.txt
+++ 2.6-mm/Documentation/filesystems/vfs.txt
@@ -1,10 +1,9 @@
-/* -*- auto-fill -*- */
Overview of the Virtual File System
- Richard Gooch [EMAIL PROTECTED]
+ Original author: Richard Gooch [EMAIL PROTECTED]
- 5-JUL-1999
+ Last updated on August 21, 2005
Conventions used in this document section
@@ -15,9 +14,6 @@ right-hand side of the section title. Ea
subsection at the right-hand side. These strings are meant to make
it easier to search through the document.
-NOTE that the master copy of this document is available online at:
-http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt
-
What is it? section
===
@@ -126,14 +122,18 @@ It's now time to look at things in more
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;
+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,
@@ -141,51 +141,96 @@ struct file_system_type {
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
+ get_sb: the method to call when a new instance of this
filesystem should be mounted
+ kill_sb: the method to call when an instance of this filesystem
+ should be unmounted
+
+ owner: for internal VFS use: you should initialise this to NULL
+
next: for internal VFS use: you should initialise this to NULL
-The read_super() method has the following arguments:
+The get_sb() 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
+ get_sb() method
+
+ int flags: mount flags
+
+ const char *dev_name: the device name we are mounting.
void *data: arbitrary mount options, usually comes as an ASCII
string
int silent: whether or not to be silent on error
-The read_super() method must determine if the block device specified
+The get_sb() 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.
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
+get_sb() 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.
+Usually, a filesystem uses generic one of the generic get_sb()
+implementations and provides a fill_super() method instead. The
+generic methods are:
+
+ get_sb_bdev: mount a filesystem residing on a block device
+
+ get_sb_nodev: mount a filesystem that is not backed by a device
+
+ get_sb_single: mount a filesystem which shares the instance between
+ all mounts
+
+A fill_super() method implementation has the following arguments:
+
+ struct super_block *sb: the superblock structure. The method fill_super()
+ must initialise this properly.
+
+ void *data: arbitrary mount options, usually comes as an ASCII
+ string
+
+ int silent: whether or not to be silent on error
+
struct super_operations section
===
This describes how the VFS can manipulate the superblock of your
-filesystem. As of kernel 2.1.99, the following members are defined:
+filesystem. As of kernel 2.6.13, the following members are defined:
struct super_operations {
- void (*read_inode) (struct inode *);
-
