VFS MODULE writers HEAD's up!!! Fixing Cascaded VFS modules

[Stefan (metze) Metzmacher]

At 00:37 19.04.2003 +0200, Jelmer Vernooij wrote:
>On Fri, Apr 18, 2003 at 11:41:16PM +0200, Stefan (metze) Metzmacher wrote 
>about 'VFS MODULE writers HEAD's up!!! Fixing Cascaded VFS modules':
> > the current design of handling the cascaded vfs modules.
>
> > is broken for the following setup:
>
> > [share1]
> >         path = /data1
> >         vfs object = audit recycle
>
> > [share2]
> >         path = /data2
> >         vfs object = audit fake_perms
>
> > 1.)Since the audit module has a global:
> > vfs_ops default_vfs_ops; struct
>
> > this can only holds the recylce vfs_ops OR the fake_perms ops.
>
> > So what we need is, a function witch returns the default vfs_ops
> > for the module and the current onnection.
>
> > So Jelmer and me have choosen a solution for this.
>The proposal we agreed upon was for the 'truly' fixed
>interface (e.g. also fixing the point 4 you mentioned), which
>would probably go into 3.1. Also that
>we shouldn't make any changes in the current interface for 3.0, but I'm not
>really sure whether your current patch is the right way to get VFS
>correct for 3.0.

I didn't make reall changes to the current interface!
old modules are still supported without a change.

I think the point is not to touch the vfs_function prototypes,
but to touch the loading via the new modules should be no problem

because the change to the smb_register_vfs() fn should not be a problem,
because this is in 3_0 only for 2 days now :-)

I would be fine with anyother solution too that provides the same functionality
as my approach and also make the fallback to the old modules possible!

And I still thing cascaded modules with different configurations on 
different shares should be supported in 3.0!
(It doesn't matter how :-)


metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze at metzemix.de>