>
> On Wed, 8 Mar 2000, Alexander Viro wrote:
.... lots of useful stuff about my vfs.sgml .....
Thanks for all that. I will go through your comments and the latest
source and get it more up-to-date/accurate.
> >
> > 7) "The one interesting usage of the field [->s_type] is in
> > fs/nfsd/vfs.c:nfsd_lookup() where it is used to make sure that a
> > proc or nfs type file-system is never accessed via NFS."
> > That's a bug. Thanks for pointing out. knfsd is not a place for such tests.
As you probably noticed, I fixed this some time ago - but after I
wrote about it.
> >
> > 9) ->read_inode() and iget(): the former should not be there. The latter is
> > a convenience, but it's only for filesystem itself. And it's not mandatory -
> > check ncpfs in 2.3.0 for example of how it should not be used. See also the
> > entry for "blivet" in Jargon File... As for nfsfh.c - right, we need an
> > analog of VOP_FHTOVP(), but it should return dentry instead of inode. Work
> > in progress...
I've been working in that direction too. Hopefully our efforts will
meet nicely in the middle.
In 2.3.51 I restructued the filehandle management code so that it uses
a new format for filehandles which is more flexable.
It explicitly separates the parts the knfsd needs to know about
(i.e. identifying the filesystem/export point) from the parts that the
underlying filesystem needs to know about (identifying the file within
the filesystem).
We can now fairly easily pass an opaque sting of bytes to the
filesystem and ask for a dentry, or pass a dentry and ask for a string
of bytes.
I look forward to seeing your filehandle <--> dentry code.
NeilBrown
