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

[Michael Adam]

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

What is the difference, symbol-wise, between two modules that
include a given .c file and hence create just a single .o file
each and two modules that link the same additional .o file to
their own .o files? Is it that the symbols of the shared extra
.c/.o file would have to be published? If this is the problem,
I understand that the inclusion might solve the issue when we
create shared objects for the two modules. But what if we
link the two .o files directly (and hence) statically into (e.g.) smbd,
wouldn't the private symbols collide in smbd as well?

I think (and may be mistakten) that the original motivation of
using the include for the vfs_acl_common.c file was the
define "ACL_MODULE_NAME" that was done in the vfs_acl_tdb and
vfs_acl_xattr modules and used in the common file for the module
parametric conf options. To me this appears simply as lazyness. ;-)
Jeremy, I apologize in advance if I am not doing you justice here...

To my preference, including .c files is a pattern that we have
to avoid by all means in samba code. The only exception
for the rule I would consent to is the case where we want to
create a standalone unit test program that should test private
functions of a single given .c file.

I really have a limited understanding of the linking
internals/problems here and would like to understand this
better.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20121030/ba8ac2c7/attachment.pgp>