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

[Stefan (metze) Metzmacher]

At 14:34 19.04.2003 +0200, Simo wrote:
>On Fri, 2003-04-18 at 23:41, Stefan (metze) Metzmacher wrote:
>
> > this old module:
> > static int example_stat(struct connection_struct *conn, const char *fname,
> > SMB_STRUCT_STAT *sbuf)
> > {
> >          return default_vfs_ops.stat(conn, fname, sbuf);
> > }
> >
> > the new module:
> > static int example_stat(struct connection_struct *conn, const char *fname,
> > SMB_STRUCT_STAT *sbuf)
> > {
> >          VFS_DEFAULT_OPS;
> >
> >          VFS_HANDLE_GET_OPS(conn, return -1);
> >
> >          return default_vfs_ops->stat(conn, fname, sbuf);
> > }
>
>what does exactly VFS_HANDLE_GET_OPS do?

we'll have a DLIST with vfs_handle_structs and each vfs_handle_struct contains
a vfs_ops default_vfs_ops struct.

and this MACRO will find the vfs_handle_struct for the current module and
returns a pointer to the default_vfs_ops struct.

>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!

>the bet sthing would be to have a chain of operations for each service,
>so that each module is linked to a ring of the chain and calls the next
>one.
>
>
>service
>  |
>  |-- module 1 operations
>  |-- module 2 ops
>  |-- module 3 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);
}

or

int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd);
{
         vfs_ops *default_vfs_ops = handle->next->vfs_ops;

         return default_vfs_ops->close(handle->next,fsp,fd);
}

but I would preferr the first one...

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



> > 2.) Since we have the new module loading system
> > we can remove the vfs_init() and vfs_done() functions
> > (we allready have vfs_connect() an vfs_disconnect() to manage the per
> > connection stuff)
> >
> > the smb_register_vfs() fn will directly register the vfs_op_tuple array.
>
>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()



> > 3.) Limitation of the system:
> >
> > we can't allow:
> >
> > vfs object = recycle audit recycle
> >
> > but I think such a combination doesn't make any sense.
>
>not for the recycle, but it may do for a caching module for example.

Good point :-)


> > and if someone would really need it, he should copy the recycle.c to 
> recycle2.c
> >
> > let the recycle2.c register under name 'recycle2'
>
>not acceptable, would be an administrative pain imho.

yep


> > and then he could use:
> >
> > vfs object = recycle audit recycle2
> >
> > 4.) Does anybody has any objections against this system?
> >
> > It would be really cool to get a fast feedback!!!
> > Because I think this fix should be get its way into SAMBA 3.0 !!!
>
>
>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?



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