s3-vfs: split @GMT token filter code into a common .c

[simo]

On Tue, 2012-10-30 at 19:30 +1100, Andrew Bartlett wrote:
> On Tue, 2012-10-30 at 08:41 +0100, Volker Lendecke wrote:
> > On Mon, Oct 29, 2012 at 07:04:38PM +0100, David Disseldorp wrote:
> > > Hi,
> > > 
> > > I've recently been working on a Snapper vfs module[1] to propagate FSRVP
> > > snapshot create/delete requests to snapperd via D-Bus.
> > > 
> > > The module makes use of @GMT token filtering hooks currently provided by
> > > vfs_shadow_copy2. Therefore, I'd like to split these hooks into a
> > > common source for use by both modules, similar to the current
> > > relationship between vfs_acl_tdb.c, vfs_acl_xattr.c and vfs_acl_common.c
> > > 
> > > Please see following patch. Feedback appreciated.
> > 
> > While it is a good thing to centralize as much of that logic
> > as possible, please do not #include a .c file. I really,
> > really do not like it in the acl modules and another use of
> > that pattern should be avoided if at all possible. If that
> > means we have to put those routines into core smbd, not
> > sure.
> 
> The challenge here, as I see it, is the autoconf build.  With the
> infinite flexibility we currently offer on module static/shared we can't
> get this the sensible way, which is sharing a .c/.o file in the link
> unit, and the autoconf build doesn't give us easy private shared
> libraries.
> 
> The reason we can't just have both modules link in the extra .c/.o file
> is that if both are selected static, the symbols would collide in smbd.

Use a macro to define the function name based on the module, this way we
use the same code but can link it in multiple modules w/o symbol
clashes.

> One other way to avoid this would be to reduce the autoconf build to the
> basic file server, or at least not every single vfs module, now that we
> are past the branch point for Samba 4.0.

no.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>