vfsx17.patch available - continuing vfs work (expert developers only)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    The next patch is ready.  I haven't dealt with the nfs server, unionfs,
    or nullfs yet, I've been working around the edges cleaning things up.

	fetch http://leaf.dragonflybsd.org/~dillon/vfsx17.patch

    This patch cleans up the relookup() code used by *_rename() VOPs, removes
    a great deal more of the 'old' API and old infrastructure, including
    nearly all the CNP_* flags, and simplifies the *_lookup() VOPs.  It also
    documents a bunch of stuff, makes systat's namecache stats work again,
    and fixes a few bugs that David Rhodus found and a few more that I found.
    As of this patch the new namecache topology is officially an 'unbroken'
    topology, with no special cases left.

    I took a pass at the NFS server but the result was such a big mess I
    backed it out of my local tree in disgust.  The issue with the NFS server
    is that it is given a file handle (basically an inode number) by the
    remote client which it uses to obtain the vnode.  Unfortunately this
    means that it might obtain a vnode that is way out in the middle of
    nowhere, with no namecache topology leading to it.

    I tried to solve the problem by creating a 'dummy' namecache record
    for the vnode but the lack of knowledge about the filename of the vnode
    resulted in duplicate namecache records being created which required a
    mess of code to resolve.  It also didn't solve the ".." lookup problem
    which NFS servers have to be able to handle.

    I am going to try again tomorrow, this time by doing a brute-force
    ".." / directory-scan loop to resolve the namecache topology leading to
    the vnode the client wanted.  This sounds burdensome but, in fact, while
    it has a lot of overhead it doesn't actually have to happen very often
    because the namecache is, well, cached.  So the entry in question is
    already likely to be in the cache and if it isn't its parent directory
    almost certainly is.  So despite the brute-force nature of the solution 
    I think this will be an efficient solution.

    Maintaining an unbroken topology also has an interesting side effect in
    that it becomes possible to safely export multiple subdirectories of
    the same filesystem with *different* export permissions, without having
    to hand the whole filesytem to the client... something that cannot be
    done with most existing NFS servers.  I don't plan on implementing the
    feature myself, I have to move onto the other items on my list, but I 
    will write it up for anyone who wants to have a go at it once I get
    the NFS server working properly again.

    Still TODO:	NFS server, unionfs, nullfs. 

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>