Messages in this thread Patch in this message | | | Date | Thu, 30 Apr 1998 23:33:46 -0400 (EDT) | From | "C. Scott Ananian" <> | Subject | PATCH: 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
| |