aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems/vfs.txt
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2011-03-16 09:07:58 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2011-03-16 16:48:06 -0400
commit1a102ff92579edeff5e3d5d3c76ca49977898f00 (patch)
tree5585d724c8a996b770bb7a621563a7535a8c0496 /Documentation/filesystems/vfs.txt
parent011949811b946bd3b72fca71200f197c6168a5f8 (diff)
vfs: bury ->get_sb()
This is an ex-parrot. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation/filesystems/vfs.txt')
-rw-r--r--Documentation/filesystems/vfs.txt56
1 files changed, 32 insertions, 24 deletions
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 94cf97b901d7..ef0714aa8e40 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -95,10 +95,11 @@ functions:
95 extern int unregister_filesystem(struct file_system_type *); 95 extern int unregister_filesystem(struct file_system_type *);
96 96
97The passed struct file_system_type describes your filesystem. When a 97The passed struct file_system_type describes your filesystem. When a
98request is made to mount a device onto a directory in your filespace, 98request is made to mount a filesystem onto a directory in your namespace,
99the VFS will call the appropriate get_sb() method for the specific 99the VFS will call the appropriate mount() method for the specific
100filesystem. The dentry for the mount point will then be updated to 100filesystem. New vfsmount refering to the tree returned by ->mount()
101point to the root inode for the new filesystem. 101will be attached to the mountpoint, so that when pathname resolution
102reaches the mountpoint it will jump into the root of that vfsmount.
102 103
103You can see all filesystems that are registered to the kernel in the 104You can see all filesystems that are registered to the kernel in the
104file /proc/filesystems. 105file /proc/filesystems.
@@ -107,14 +108,14 @@ file /proc/filesystems.
107struct file_system_type 108struct file_system_type
108----------------------- 109-----------------------
109 110
110This describes the filesystem. As of kernel 2.6.22, the following 111This describes the filesystem. As of kernel 2.6.39, the following
111members are defined: 112members are defined:
112 113
113struct file_system_type { 114struct file_system_type {
114 const char *name; 115 const char *name;
115 int fs_flags; 116 int fs_flags;
116 int (*get_sb) (struct file_system_type *, int, 117 struct dentry (*mount) (struct file_system_type *, int,
117 const char *, void *, struct vfsmount *); 118 const char *, void *);
118 void (*kill_sb) (struct super_block *); 119 void (*kill_sb) (struct super_block *);
119 struct module *owner; 120 struct module *owner;
120 struct file_system_type * next; 121 struct file_system_type * next;
@@ -128,11 +129,11 @@ struct file_system_type {
128 129
129 fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) 130 fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
130 131
131 get_sb: the method to call when a new instance of this 132 mount: the method to call when a new instance of this
132 filesystem should be mounted 133 filesystem should be mounted
133 134
134 kill_sb: the method to call when an instance of this filesystem 135 kill_sb: the method to call when an instance of this filesystem
135 should be unmounted 136 should be shut down
136 137
137 owner: for internal VFS use: you should initialize this to THIS_MODULE in 138 owner: for internal VFS use: you should initialize this to THIS_MODULE in
138 most cases. 139 most cases.
@@ -141,7 +142,7 @@ struct file_system_type {
141 142
142 s_lock_key, s_umount_key: lockdep-specific 143 s_lock_key, s_umount_key: lockdep-specific
143 144
144The get_sb() method has the following arguments: 145The mount() method has the following arguments:
145 146
146 struct file_system_type *fs_type: describes the filesystem, partly initialized 147 struct file_system_type *fs_type: describes the filesystem, partly initialized
147 by the specific filesystem code 148 by the specific filesystem code
@@ -153,32 +154,39 @@ The get_sb() method has the following arguments:
153 void *data: arbitrary mount options, usually comes as an ASCII 154 void *data: arbitrary mount options, usually comes as an ASCII
154 string (see "Mount Options" section) 155 string (see "Mount Options" section)
155 156
156 struct vfsmount *mnt: a vfs-internal representation of a mount point 157The mount() method must return the root dentry of the tree requested by
158caller. An active reference to its superblock must be grabbed and the
159superblock must be locked. On failure it should return ERR_PTR(error).
157 160
158The get_sb() method must determine if the block device specified 161The arguments match those of mount(2) and their interpretation
159in the dev_name and fs_type contains a filesystem of the type the method 162depends on filesystem type. E.g. for block filesystems, dev_name is
160supports. If it succeeds in opening the named block device, it initializes a 163interpreted as block device name, that device is opened and if it
161struct super_block descriptor for the filesystem contained by the block device. 164contains a suitable filesystem image the method creates and initializes
162On failure it returns an error. 165struct super_block accordingly, returning its root dentry to caller.
166
167->mount() may choose to return a subtree of existing filesystem - it
168doesn't have to create a new one. The main result from the caller's
169point of view is a reference to dentry at the root of (sub)tree to
170be attached; creation of new superblock is a common side effect.
163 171
164The most interesting member of the superblock structure that the 172The most interesting member of the superblock structure that the
165get_sb() method fills in is the "s_op" field. This is a pointer to 173mount() method fills in is the "s_op" field. This is a pointer to
166a "struct super_operations" which describes the next level of the 174a "struct super_operations" which describes the next level of the
167filesystem implementation. 175filesystem implementation.
168 176
169Usually, a filesystem uses one of the generic get_sb() implementations 177Usually, a filesystem uses one of the generic mount() implementations
170and provides a fill_super() method instead. The generic methods are: 178and provides a fill_super() callback instead. The generic variants are:
171 179
172 get_sb_bdev: mount a filesystem residing on a block device 180 mount_bdev: mount a filesystem residing on a block device
173 181
174 get_sb_nodev: mount a filesystem that is not backed by a device 182 mount_nodev: mount a filesystem that is not backed by a device
175 183
176 get_sb_single: mount a filesystem which shares the instance between 184 mount_single: mount a filesystem which shares the instance between
177 all mounts 185 all mounts
178 186
179A fill_super() method implementation has the following arguments: 187A fill_super() callback implementation has the following arguments:
180 188
181 struct super_block *sb: the superblock structure. The method fill_super() 189 struct super_block *sb: the superblock structure. The callback
182 must initialize this properly. 190 must initialize this properly.
183 191
184 void *data: arbitrary mount options, usually comes as an ASCII 192 void *data: arbitrary mount options, usually comes as an ASCII