Re: VFS: C99 sparse format for struct vfsops

Hiten Pandya wrote:
> > Consider this going forward: someone adds a new VFSOP to the
> > list of allowable VFSOPs, and the vfs_init() doesn't have any
> > specific code for it.
> 
>         Considered.  Now consider this, would you argue this about the
>         sparse cdevsw initialisation in make_dev()?  I hardly think so.
>         It does a good job of centralising things, and making it easier
>         for all of us.

This is a different thing entirely... you are not adding
elements in the cdevsw case.

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).

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.


> > This could happen with a new VFS implementation that gets loaded
> > as a module.  While the current code can't really handle this
> > well, the changes move us further away from ever being able to
> > handle something like this.  8-(.
> 
>         But, up to now, this has not been a problem, unless you make it
>         so.  I don't think I even needed to add conditional checks for
>         the mount and nmount ops in vfs_init.  These are things which
>         would be fault of developer if he doesn't update the
>         `centralised' code, not yours or mine, or FreeBSD's.
> 
>         I also don't see the point of having a gazillion default ops
>         being inited in every fs specific vector when we can just do
>         this centrally.

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.

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.

Your change makes this impossible for VFSOPS.

-- Terry