>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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:10 EST