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

[Simo]

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?
imho it's not acceptable to reget all the option at each operation.
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


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


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

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

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


Simo.

-- 
Simo Sorce    -  idra at samba.org
Samba Team    -  http://www.samba.org
Italian Site  -  http://samba.xsec.it