On Tue, Jun 18, 2002 at 06:29:10PM +1000, Andrew Bartlett wrote: > Simo Sorce wrote: > > > > On Tue, 2002-06-18 at 09:05, Andrew Bartlett wrote: > > > Simo Sorce wrote: > > > > + /* Handles on dlopen() call */ > > > > + smb_vfs_dl_handle *dl_handle; > > > > + void **vfs_private; > > > > > > Why a void** ? > > > > Because you really do not know what the module wants to put there, can > > be anything. > I would have a void* thats all. void** is used to provide each module each own vfs_private pointer so that each module receives its id on registration and then uses conn->vfs_private[id] for storing private data. Otherwise only one module would have its private data.
> > no because you can have a different path for any different share, each > > with it's own set of modules. > > I'll defer on this one - its not a major issue. Yes, idea was to have loadpath configurable per share with possible global path which can be overriden if needed. > > > Why? I think we should return errors on failure... > > > > if the dl_handle is null we have an error. > > I don't like signaling errors/status by changing a paratmer - I think it > is better to actually look at the return value. Thats the point I was > trying to make. That function is static and its logic is different from what it was in 2.2.x. Please look closer. > > I think it is important. > > we already are backward compatible for lot of things, why not modules > > that will likely be built outside the samba team and need a bit more > > stable interface OR backwards compatibility? > I just don't want to be maintaining backward compatibilty forever. We already have a pain of constantly changing VFS interfaces -- ask third party developers who use VFS interface (especially antivirus ones) what they think about it... Remember, people are required to support various builds of samba with their product and if we were able to minimize unneeded breaks... -- / Alexander Bokovoy --- Worrying is like rocking in a rocking chair -- It gives you something to do, but it doesn't get you anywhere.
