DragonFly kernel List (threaded) for 2004-08
Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)
: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?
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
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