You're probably right. However, we'd need to move to a dentry-centric
world-view eventually in any case: the current inode-based stuff doesn't
work too well if we want to get full advantage of the things that the
dentries offer us.
For example, thanks to the dentry model we should actually be able to do
loopback mounts with no extra cost. Loopback mounts are essentially "hard
linked directories", but with the added caveat that ".." for the
hardlinked directory points back _both_ ways (depending on how you got to
the point).
Loopback mounts used to be pretty much impossible to do before - I had
thought about it and the only way to do them reliably would be to
essentially alias all the inodes that you traverse in the looped back
mount. However, with dentries the loopback problem essentially goes away:
we don't need to alias the inode at all, and the dentry ".." following
automatically gives us what we want.
However, there is one ugly exception: "fchdir()". For fchdir() to work
correctly we must have the correct _dentry_ in the "struct file", not just
the inode - because if we have the inode in the struct file, then we
cannot distinguish between different loopback mounts..
Also, as the dentries give us full pathname information, we're going to
start using it. But if we want to get the path-name of any open file in
the filesystem we again need the _dentry_ to the file, not the inode,
because otherwise we cannot distinguish between two pathnames that share
the same inode (normal hard links).
The full path name information is very cool: we can do a "getcwd()" system
call that is going to be a few orders of magnitude faster than the
traditional way of doing "getcwd()".
Linus