Re: approach on getting nullfs to work again

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Wed, Feb 09, 2005 at 09:38:15PM -0800, Matthew Dillon wrote:
:> :okay. this means all vop calls that don't work with struct namecache *=20
:> :parameters just get passed through to the underlying filesystem and all vop=
:> :=20
:> :calls that cope with struct namecache * need to wrap, grab the "real"=20
:> :namecache entry and pass it down?
:> 
:>     VOP calls, yes.  VFS calls (as Joerg indicates, fstatfs) might be a
:>     different matter, but even there the best solution might actually be
:>     a high level kernel solution ('gee this path is going through a nullfs
:>     mount') rather then a low level VFS solution.  It could be just a matter
:>     of adding an ncp argument to the VFS op in question.
:
:What happens if we use the namecache entry in fp->f_data and follow that
:to the actual vnode before VOP calls? Even including a namecache entry
:directly in f_data and setting it to NULL for sockets?

    This won't work because an active vnode will not always have a namecache
    association.  e.g. if you open() a file and then remove() the file.
    This is why there is a separate f_ncp.  A namecache pointer will not be
    destroyed while a reference is held on it, and will not be invalidated 
    while held locked (except by the holder), but it can still be 
    invalidated at any other time and it's nc_vp vnode association *WILL* be
    destroyed in that case.  Furthermore, in the case of rename() and other
    operations if you are e.g. renaming-over a target file, the namecache
    pointer associated with the original target will be marked destroyed and
    can *never* be reconstituted (at least not as an assocition with the
    original target vnode which is no longer in the namespace).

    So a namecache pointer is not a direct replacement for a vnode.

:>     In fact, *ALL* VOP or VFS ops that specify a file path have the same
:>     ability to distinguish between namespaces as VOP ops that pass namecache
:>     pointers, because path ops will also have access to the related namecache
:>     pointer.
:
:Yeah, so we would want to convert the VFS calls to get a namecache entry
:as well. If we have that, I don't have any problems with using the vnodes
:directly.
:
:Joerg

    Possibly, yes.  I would call that 'stage 2' or 'stage 3'.

    ncp->nc_mount should be consistent now because, amoung other things,
    all the VOP_*() compatibility macros are now getting the ops structure
    via ncp->nc_mount->mnt_vn_use_ops.  This means that a resolved and locked
    namecache pointer can replace the use of a mount pointer in most VFS
    calls.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>