Re: VFS: C99 sparse format for struct vfsops

Hiten Pandya wrote:
> On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote:
> > This is a different thing entirely... you are not adding
> > elements in the cdevsw case.
> 
>         Er, huh?  Did you read Poul's HEADSUP mail for cdevsw sparse
>         init?

Yes.  You are not adding new structure elements with previously
unknown entry points; it's just not possible with cdevsw.

With the VFS code, you *could* add new decriptors for previously
unknown VOP_ types, if you are willing to replace the elements
of the default_vnodeop_entries[] array, and re-vfs_init() the
vnodeopv_entry_desc's for the already mounted FS instances.


> > The VFSOP case is less of a problem than the VOP case, but it's
> > still a problem.  Poul broke the VOP case a long time ago, when
> > he added the default stuff, since there is no way to add a new
> > default to an already existing array, and the entries with a
> > default can't be proxied (e.g. over the network or to user space
> > via a descriptor, per John Heidemann's original design for VFS
> > stacking in UCLS's FICUS).
> 
>         OK, we are moving away from UCLS' FICUS.  Could you kindly
>         provide me with some examples, and practicle use of this
>         ``adding'' a new default in an already existing array?

Yes.  For example, suppose you added an new FS type to the
kernel, and it supported a previously unknown VOP_TRANSACT()
entry point that took a vp and a flag which was one of the
set {VTA_BEGIN, VTA_ABORT, VTA_COMMIT}, and you added a new
system call to externalize the ability to access these
transactions to user space database programs.

Then you stacked a stacking layer for doing management of disk
quotas on top of it, and that stacking layer didn't know about
VOP_TRANSACT() at all.  But you wanted it to work.


> > By making this change, you are basically changing it from a
> > data structure to something that has to be coded, and there's
> > no way to add code for a new entry that needs to be defaulted
> > to a non-NULL value --  which they all have to be.
> 
>         Huh? Come again please?  Could you ellaborate on this point as
>         it is sending me in circles.  I don't see how it is not possible
>         to do that, please provide a practical case, so I can
>         understand.

Because the code is required to fill in the sparse entries
that are not filled in in the array byt the user.  If you add
a new VOP_ entry type that was not known before (e.g. our
vop_transact_desc entry), then you need to add code to set its
defaults for any FS that didn't make an entry for it.

Only you can't, because there's nohooks for adding code to
vfs_register() to do the equivalent of what your patch does,
e.g.:

+       if (vfsops->vfs_start == NULL)
+               /* make a file system operational */ 
+               vfsops->vfs_start =     vfs_stdstart;

The principle is the same for new VFSOPS as for new VOPS: you
can't grow the list, if you have to add code for each entry
you add.


> > As I said above: Poul broke this for VOPs.  It doesn't make
> > sense to say "It's broken for VOPs now, so it's OK to break it
> > for VFSOPs, too".
>         ...
> > It's "not been a problem", as you say, so far, because the VFS
> > stacking in FreeBSD has been broken for a long time.  Breaking
> > it more just moves us farther away from ever fixing the code,
> > which I think is a bad thing.
> 
>         That is such of a broad statement..=

Yes, but it's accurate.


> > If, at some point, we get rid of the "default" crap, then it
> > would be possible to add VOPs to a running kernel by just
> > reallocating the VOP array for each mounted FS to add the entry
> > to the end of the array.
> 
>         And here is the question again, why would you want to add VOPs
>         to a running kernel?  Please provide some examples, or practical
>         cases.

See my transaction example.  You might also have a VFSOP for
a cleaner entry point, e.g. for an LFS or XFS or JFS.

As to why: so I can load an FS module into a ditribution kernel
without having to recompile everything.  For example, the
commercial AFS module.


> > Your change makes this impossible for VFSOPS.
> 
>         Awaiting your reply...
>         Cheers.

I hope the above has clarified the issue for you: it's because
of the VFSOP-specific code you are required to add to the
vfs_register() in kern/vfs_init.c.

-- Terry