lkml.org 
[lkml]   [1998]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectPATCH: fs/namei.c, vfs documentation updates.
This didn't get put into 2.1.99, so back out for comments it goes.
This patch fixes the documentation errors in fs/namei.c and
Documentation/filesystems/vfs.txt with regard to symlink behavior
[in particular, <fs>_follow_link() and <fs>_readlink()].

No code is changed, just documentation, so this shouldn't break anything.

I got rid of the fluffy line-break changes of the previous version of this
patch, to pare it down to the bare essentials.
--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/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:
--- 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)
=====================================================
@@ -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]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.464 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site