Messages in this thread | | | Date | Wed, 1 Mar 2000 15:28:17 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Linux's future: //posix/ipc, //root and so on ? |
| |
>superior VFS design -- except when you need to write an NFS server. >Not being able to do open_by_inode() is sometimes _really_ annoying. >Just look at the mess in fs/nfsd/nfsfh.c and tell me how this is superior >over a simple iget() ?
RTFSource. BSD one, that is. They _DO_ _NOT_ _USE_ _iget()_ in nfsd. What they do (and we ought to do) is /sys/nfs/nfs_subs.c:1943: error = VFS_FHTOVP(mp, &fhp->fh_fid, vpp); It's _not_ an iget(). It's whatever the friggin' filesystem prefers to use and they also have an operation opposite to this one.
I have a patch that moves nfsfh code (and simplifies it really big way, along with removing a bunch of races) into filesystems (so far only ext2). It's not nearly as nasty as the current variant. It will go somewhere about this weekend - we'll have to change VFS locking a bit before that (and solve the damned locking issues with target of rename() in bargain).
Getting the decent replacement for iget() (i.e. one that would be fs-specific and would return proper dentry) is not hard. Current code tries to be too generic - it wants to be implemented in terms of iget() and <barf> readdir(). Which is _really_ wrong way to go - it doesn't make sense for a lot of filesystems _and_ it sucks in terms of locking for the rest. If we make foo_lookup() aware of the situation (== aware of the fact that there may be a subtree trying to join the main) we can toss most of this shit away.
And forget about open_by_inode() - you will not get it. It simply doesn't make sense for most of filesystems. Now, an interface that would give you fhandle by name/opened file and opened file by fhandle actually makes sense. But st_ino from stat() is _not_ a suitable interface for that.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |