namecache, stage 2 of 3

Matt Dillon posted a patch for the next stage of his namecache work. I’m pasting the intro here, where he talks about what this patch does, and some of what the last stage will do.

This is the stage-2 namecache patch. It should work pretty much the
same as the namecache works now except I have reorgranized the namecache
structure’s topology the way it will need to be to move forward.

Originally vnodes contained two lists: a list of namecache entries
for which the vnode is the ‘parent directory’, and a list of namecache
entries for which the vnode is the target (child in a directory). The
namecache structure would contain a reference to the two vnodes but
was otherwise disconnected from other namecache structures. The problem
with the old methodology is that it is impossible to reverse-engineer
multiple distinct paths flowing through the same vnode.

The new topology is based around the namecache structure itself. The
structure contains a parent pointer, a list of children, and a reference
to a single vnode. A vnode then has a list of all the namecache
structures flowing through it.

With the new topology we will be able to keep paths distinct by recording
a pointer to the namecache entry instead of the vnode as the ‘directory’
being searched, and as the ‘current directory’, ‘root directory’ and
‘jail directory’. This is what stage-3 is going to do. Amoung other
things it will allow you to ‘mount’ the same filesystem or a subdirectory
at multiple points in the directory tree without having to use a null
filesystem, and without causing the system to get confused vis-a-vie the
use of “..”.

There are many other uses once stage-3 is in… for example, you could
literally cut-and-paste pieces of a filesystem together to form a new
topology that shares the related vnodes but otherwise appears as a
distinct directory tree in the system. It will be possible to
implement the concept of VFS ‘environments’ that I have been positing
for the last few months simply by writing a VFS that does nothing more
then resolve namecache issues, allowing actual operation within the
‘environment’ to occur without any significant interaction with the
environment once things are cached in the namecache. VERY important.