> The question is how to get that dentry, and how to keep it up to date.
> There are two possibilities I see.
> 1) Keep a known path in the inode by which we can get a default
> dentry.
> 2) Keep a dentry field in struct page (possibly replacing the inode
> field), to use when writing the page. And is updated when we
> notice the page is dirty by a writer.
3) Revert readpage() and writepage() to using inodes.
My belief is that readpage and writepage should take the inode as an
argument, as the mm model implicitely assumes that an inode is the single
instance of the backing store for a file. A target design for the vfs
should be decided on, and the code then made to conform to that. Some
ideas: any operation having to do with a particular instance of a file
should be a dentry operation. This includes things like open, stat,
readlink... almost all current inode operations. This leaves only a few
low-level operations for inodes, which shouldn't have anything to do with
dentries. If people agree to this sort of design (they did earlier), I'll
redo the patch I did (was for .52, but it wasn't finished until major
dentry changes completely broke it). Note that there's major hell with
procfs if the ability for a proc inode to have its own inode operations is
desired. But that ability *could* be completely ignored.
-ben