Building VFS modules out of tree

[Richard Sharpe]

On Mon, Mar 31, 2014 at 3:33 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> I don't think this is about WAF or autoconf.  If we genuinely want
> external folks to be able to build modules for this, we need to publish
> everything as a public header file and library to link to, then watch
> for changes with the same ABI tracking we use elsewhere.
>
> Then users can build against those using whatever tools they choose,
> just as waf isn't needed to link against ldb, or libsmbclient.
>
> The difficulty is as seen in the attempts to allow building of external
> passdb modules, where you see great difficultly in defining how much of
> the internals of Samba need to be in the ABI for external passdb
> modules.  That is even before we start to touch on ensuring that the
> elements in the ABI are consistently represented without reference to
> our configure tests and config.h.

This is a useful point to bring up this discussion again.

It is true that rather too much information is disclosed to VFS
modules, or rather, too many symbols are available to them.

In my experience, modules often use DEBUG statements, which relies on
linking against those symbols, and, of course, they use
SMB_VFS_SOME_VFS_FUNC_NEXT for the most part, which is a symbol that
is visible in the smbd code proper. The worst of these is
vfs_acl_xattr, which directly calls functions in the smbd to construct
ACEs, ACLs, etc. They also tend to use TALLOC and the tevent stuff
these days.

One way to avoid all this would be to severely constrain what is
visible to module writers, but perhaps the bigger problem is all the
data structures that we pass in that they need to understand, like the
FSP, SDs and so forth.

So, we could pass to the module, at module init time, and array of
useful function pointers, like DEBUG, and each function in a VFS
module, when called, would be passed the next module pointer as one of
its parameters. Then we would still have to make available the
structure definitions that modules would need

However, the big cost of doing this is that all existing modules would
have to be fixed to use the new scheme ...

Hmmm, more thought is needed to figure out how to do this. Maybe more
input is required from interested parties and OEMs.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)