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

Alexander Bokovoy a.bokovoy at sam-solutions.net
Tue Apr 22 06:57:39 GMT 2003


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.

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

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

> >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.
-- 
/ Alexander Bokovoy
---
Too much is just enough.
		-- Mark Twain, on whiskey


More information about the samba-technical mailing list