Re: VFS: C99 sparse format for struct vfsops

Paul Richards wrote:
> On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
> > On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
> > > How can you add an interface at runtime?
> >
> > By loading a kernel module. If I load e.g. the agp kernel module, I add
> > the agp_if interface to the kernel.
> 
> Yes, I know that you can load a pre-compiled interface at runtime
> and thereby add that interface, but you can only "create" interfaces
> at build time because each method in the interface is uniquely
> identified by a kobjop_desc struct, which is what I was referring to.

The data structures associated with VFS do not have this design
limitation, unless youaccidently add it (which is what started
this thread in the first place).  Since calls are by desciptor,
and descriptor reference are arbitrary, you can create interfaces
at runtime because you can add arbitrary descriptors.

The Netgraph code can also create interfaces at runtime, though
it does this in a different way (nodes who attach to them have
to know about them, so the only way to add and use a new one is
to load two modules, not one).


> > One possible way of making this slightly simpler might be to make the
> > class point at a table indexed by interface ID, each entry of which is a
> > table indexed by a method ID from that interface. This sounds fine in
> > theory but in practice, it would end up slower due to the two memory
> > accesses.
> 
> That's along the lines of what I suggested at the start of the thread :-)

I'm not sure it could be made SMP safe.  However, as to speed...
the vnops array has this same limitation on speed; you can
actually reduce this to one memory access at runtime, by
precomputing the array position for the specific interface.

The cost from doing this is that you have to rebuild all of
your already created FS instances each time you add a VOP, for
each mounted FS, so that the array reference doesn't run off
the end of decriptor list.  Another downside is that it is then
nearly impossible to proxy across a single channel (e.g. to a
filesystem developement framework in user space or across a
network) without a very expensive reverse lookup.  IMO, you
would flag the underlying FS, and not do the optimization, if
it was of one of those types.

If the VOP's are relatively lightweight, you can get about an
8% speed improvement from doing the precomputation, and avoiding
marshalling the data ito and out of a descriptor (these are
around the numbers we achieved at Artisoft, when we ported the
VFS stacking and FFS and UFS to Windows 95).

Another trick you used to be able to do, before vfs_default.c,
was to coelesce NULL layers that didn't have explicit vnode
implementations of their own (e.g. the same way UFS and FFS
are pre-coelesced).  This saves the call-through.  Actually,
you could do this for GEOM, today, if you were willing to
strip out the per-layer statistics gathering requirement; it
would let you precompute the relative offsets per layer, and
come up with a single parametric translation for an arbitrary
number of layers, so long as there was a 1:1 block mapping.
This would probably recover some of the speed lost in 5.x
from using GEOM.

-- Terry