Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Do you think it will be like a full DragonFlyBSD install but then spread 
:on to the clusters so that it is possible to log on to that virtual OS 
:the same way like I do now with a physical machine?
:
:-- 
:mph

    I think if we do it right, anything is possible.

    If each virtual 'cluster' is considered to be a 'machine', then
    theoretically one can do anything on that 'cluster' that one could
    do on a single machine, including running the installer on it :-). 

    --

    I've been looking at the mount structure and it isn't quite suitable
    as the 'management' structure I want to pass to all the VOP calls as
    the first argument.

    Instead what I think I'll do for the second stage is create a new
    structure, we'll call it 'fsmanage', for this purpose.  This structure
    will contain a pointer to the mount point and will embed the vop_ops
    operations vector (I don't want to have too many indirections to get
    to the vop_ops).  The vnode will then have a v_fm pointer to this
    management structure and we will remove v_op (now v_vops) and v_mount
    from the vnode structure.  (It's a little messy to do things that way
    because each filesystem actually needs three sets of operations vectors
    for normal files/dirs, pipes, and device nodes, but I can't think of
    a cleaner way of doing it at the moment).

    Getting rid of the 'vnode must be the first argument' dependancy that
    the current VOP subsystem has is very important for upcoming stages
    in order to be able to do namespace-locked operations where a vnode is
    not necessarily present or desired.

    I am also going to collect the cacheable and system managed portions
    of the vnode (the VM object, vattr, range locks, supporting structures
    for cache coherency, and other things) all into their own structure,
    but for now I am just going to embed that structure into the vnode
    so nothing will really have changed (yet).  I'll call that one
    'fscache'.

    But down the line I want all the kernel's high level cache management
    infrastructure to work on a 'fscache' structure rather then a 'vnode'.
    This will allow us to use the 'fscache' structure for a number of other
    purposes including, in the far future, the holding of remotely cached
    data in the cluster.  Other more esoteric possibilities include using
    such structures in pipes, sockets, block devices, and so forth.

    In anycase, it sounds complex but I actually think stage 2 will only
    take the weekend to get done.  It's mostly grunt work because all the
    VOP_*() calls in all the VFS's have to be modified to supply the new
    argument.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>