Documentation/filesystems/vfs.txt is formatted for a tab-width of 2
columns. I would like to reformat this file to use spaces instead of
tabs for readability, but haven't done so in the present patch to avoid
obscuring the documentation updates. I did succomb to the temptation to
rebreak two paragraphs of the original, though.
This patch changes documentation only, not code, but, to be safe, I
compiled the kernel after patching to be sure I didn't leave off a comment
delimiter somewhere. In short, this patch should be perfectly safe.
The patch is against 2.1.99pre3.
--Scott
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
C. Scott Ananian: cananian@lcs.mit.edu / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian
--- linux/Documentation/filesystems/vfs.txt.orig Wed Apr 29 16:21:32 1998
+++ linux/Documentation/filesystems/vfs.txt Wed Apr 29 16:33:29 1998
@@ -10,6 +10,7 @@
Hopefully this helps anyone attempting such a feat, as well as clearing up
a few important points/dependencies.
+[For proper formatting, the tab-width for this file should be 2]
register_filesystem (struct file_system_type *fstype)
=====================================================
@@ -46,8 +47,8 @@
struct file_system_type * next;
- This field points to the next file_system_type that is present in the system,
- and should be initialized to NULL.
+ This field points to the next file_system_type that is present in
+ the system, and should be initialized to NULL.
struct super_operations
=======================
@@ -101,14 +102,16 @@
int (*lookup) (struct inode *dir, const char *name, int len, struct inode **result);
[optional]
- lookup is called when the VFS wishes to have the filesystem resolve a name
- into an inode. Dir is a directory on the filesystem that [hopefully] contains
- the zero terminated string name (length len). A return value of zero indicates
- that there is a valid inode stored in *result.
-
-*** Note: lofs assumes that any filesystem returns an inode within the filesystem
- for all directory inodes. Therefore, __iget(sb,ino,0) should be used to fetch
- the inode in a filesystem's lookup routine.
+ lookup is called when the VFS wishes to have the filesystem
+ resolve a name into an inode. Dir is a directory on the
+ filesystem that [hopefully] contains the zero terminated string
+ name (length len). A return value of zero indicates that there is
+ a valid inode stored in *result.
+
+*** Note: lofs assumes that any filesystem returns an inode within the
+ filesystem for all directory inodes. Therefore, __iget(sb,ino,0)
+ should be used to fetch the inode in a filesystem's lookup
+ routine.
int (*link) (struct inode *,struct inode *,const char *,int);
[optional]
@@ -133,10 +136,12 @@
int (*follow_link) (struct inode *,struct inode *,int,int,struct inode **);
[optional]
- 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
- foreign filesystem that makes no sense....
- I threw this one out - too much redundant code!
+ follow_link must be implemented if readlink is implemented.
+ Note that follow_link can return a different inode than a
+ lookup_dentry() on the result of readlink() would return.
+ The proc filesystem, in particular, uses this feature heavily.
+ For most user filesystems, however, follow_link() and readlink()
+ should return consistent results.
int (*readpage) (struct inode *, struct page *); [optional]
int (*writepage) (struct inode *, struct page *); [mandatory with readpage]
--- linux/CREDITS.orig Tue Apr 14 07:42:11 1998
+++ linux/CREDITS Tue Apr 14 07:43:30 1998
@@ -39,6 +39,7 @@
P: 1024/85AD9EED AD C0 49 08 91 67 DF D7 FA 04 1A EE 09 E8 44 B0
D: Unix98 pty support.
D: APM update to 1.2 spec.
+D: VFS documentation update: symlinks.
N: Erik Andersen
E: andersee@debian.org
--- linux/fs/namei.c.orig Wed Apr 29 16:43:06 1998
+++ linux/fs/namei.c Wed Apr 29 16:50:49 1998
@@ -43,17 +43,24 @@
*
* The new code replaces the old recursive symlink resolution with
* an iterative one (in case of non-nested symlink chains). It does
- * this by looking up the symlink name from the particular filesystem,
- * and then follows this name as if it were a user-supplied one. This
- * is done solely in the VFS level, such that <fs>_follow_link() is not
- * used any more and could be removed in future. As a side effect,
- * dir_namei(), _namei() and follow_link() are now replaced with a single
- * function lookup_dentry() that can handle all the special cases of the former
- * code.
+ * this with calls to <fs>_follow_link().
+ * As a side effect, dir_namei(), _namei() and follow_link() are now
+ * replaced with a single function lookup_dentry() that can handle all
+ * the special cases of the former code.
*
* With the new dcache, the pathname is stored at each inode, at least as
* long as the refcount of the inode is positive. As a side effect, the
* size of the dcache depends on the inode cache and thus is dynamic.
+ *
+ * [29-Apr-1998 C. Scott Ananian] Updated above description of symlink
+ * resolution to correspond with current state of the code.
+ *
+ * Note that the symlink resolution is not *completely* iterative.
+ * There is still a significant amount of tail- and mid- recursion in
+ * the algorithm. Also, note that <fs>_readlink() is not used in
+ * lookup_dentry(): lookup_dentry() on the result of <fs>_readlink()
+ * may return different results than <fs>_follow_link(). Many virtual
+ * filesystems (including /proc) exhibit this behavior.
*/
/* [24-Feb-97 T. Schoebel-Theuer] Side effects caused by new implementation:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu