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

[Stefan (metze) Metzmacher]

At 09:57 22.04.2003 +0300, Alexander Bokovoy wrote:
>On Tue, Apr 22, 2003 at 06:47:54AM +0200, Stefan (metze) Metzmacher wrote:
> > >imho it's not acceptable to reget all the option at each operation.
> >
> > why? we just get a pointer to a vfs_ops struct. and it would be reall
> > pain to have seperate a functions to get the each single function
> > pointer!
>Because it slowdowns execution paths.

I don't understand that?

do you want:

(*_open)(vfs_handle_struct *,connection_struct *....) = 
handle->default_vfs_ops.open;

(*_close)(vfs_handle_struct *,file_struct *, int) = 
handle->default_vfs_ops.close;

(*_unlink)(vfs_handle_struct *,connection_struct *....) = 
handle->default_vfs_ops.unlink;


....

instead of a simple :

vfs_ops *default_vfs_ops = handle->default_vfs_ops;


> > Another Approach I discussed with Jelmer was:
> > to add a new parameter vfs_handle_struct *handle to each vfs function.
> >
> > so e.g.:
> >
> > now:
> > int example_close(files_struct *fsp, int fd);
> >
> > then:
> > int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd);
> > {
> >         vfs_ops *default_vfs_ops = handle->default_vfs_ops;
> >
> >         return default_vfs_ops->close(handle->next,fsp,fd);
> > }

Is this the one we can all accept?
if yes, I'll start implementing it

> >
> > This would also make 'vfs object = recycle audit recycle' possible.
> >
> > it would drop the support for old modules!
> > (for me it's not a problem :-)
>It should be clearly documented!
>I do like *handle approach too (first one). As for breaking compatibility
>with previous alpha versions, it will probably occur anyway when NT quota
>support will be integrated.

OK, Does anyone has objections to not start to implement this approach?


> > >vfs_init() and vfs_done() are a different thing of vfs_connect() and
> > >vfs_disconnect(), you may have modules that require an initialization
> > >when load and later a second initialization for each share.
> >
> > ok, for this stuff the init_module() fn would be the right place then :-)
> > instead of vfs_init() and we will never unload modules so we don't need
> > vfs_done()
>Why? We unload them after closing connection and before exiting the child.
>Some modules might use that to shutdown persistent connections (for
>example).

with the new module system we don't unload modules after closing the 
connection.
but it would be nice solution to have a smb_register_unload()
so that a module can register an unload function.
witch is called before the smbd exit.


> > >If we need a per service chain, than that's what we need to do.
> > >3.0 is not out yet, so there is no need to keep modules compatibility
> > >except perhaps for smb.conf options.
> >
> > I'm totally fine with changing the interface and drop support for old
> > modules completeply!  Alexander what do you think about this?
>I'm fine too with only one exception: we need a tutorial how to migrate
>old code to new one for both previous alpha versions and 2.2 -> 3.0 VFS
>code.

Yes, I'll write a tutorial and an example module


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