splitout of samba-debug (was: Re: [SCM] Samba Shared Repository - branch master updated)

Andrew Bartlett abartlet at samba.org
Fri Jan 16 01:20:16 MST 2015


On Thu, 2015-01-15 at 23:50 +0100, Jelmer Vernooij wrote:
> On Thu, Jan 15, 2015 at 05:33:55PM -0500, Simo wrote:
> > On Thu, 2015-01-15 at 22:24 +0100, Jelmer Vernooij wrote:
> > > On Thu, Jan 15, 2015 at 08:52:49PM +0100, Volker Lendecke wrote:
> > > > On Thu, Jan 15, 2015 at 11:19:04AM -0800, Jeremy Allison wrote:
> > > > > On Thu, Jan 15, 2015 at 07:24:38PM +0100, Jelmer Vernooij wrote:
> > > > > > 
> > > > > > OpenChange server is a plugin to Samba, it just provides another DCE/RPC
> > > > > > interface. It is no different from epmapper or winreg. It calls out to
> > > > > > various Samba functions, all of which write to the Samba logs.
> > > > > 
> > > > > As Volker points out - both of these are internal to Samba.
> > > > > 
> > > > > I don't think OpenChange should be internal to Samba, so
> > > > > let's define how we can make it work as an external plugin,
> > > > > without needing access to Samba internals.
> > > > 
> > > > Don't get me wrong -- I don't want OpenChange inside Samba.
> > > > I'm just asking whether there's a reasonable way to carve
> > > > out the essential RPC pieces that *have* to link to Samba,
> > > > leaving the rest to OpenChange via some proper IPC
> > > > mechanism, such as a unix domain socket. I could imagine
> > > > that such a RPC layer inside Samba could be pretty static,
> > > > the development I would imagine would happen somewhere else.
> > > 
> > > Sure, I agree.
> > > 
> > > We've been talking for quite some time about making openchange an external
> > > process that e.g. registers its DCE/RPC interfaces with endpoint mapper and
> > > just listens on its own ports. However, that is a non-trivial task and it has
> > > taken a backburner to higher-priority work in OpenChange.
> > > 
> > > This change (removing DEBUG) breaks OpenChange as it works at the moment, and
> > > will make it impossible for it to work with Samba 4.2. These APIs shouldn't be set
> > > in stone, but let's change Samba in conjunction with OpenChange.
> > 
> > Why not change OpenChange in conjunction with Samba ?
> > Is it so hard for OpenChange to add a DEBUG() macro by the Samba 4.2
> > release ?
> OpenChange calls a whole bunch of functions from Samba that use
> Samba's DEBUG() - their output would end up going to a different log
> file (Samba's), making it harder to debug OpenChange because you have
> to manually combine the contents from two log files.
> 
> This is not so urgent that we can't roll back this 10-line change and then
> coordinate the removal of Samba's public DEBUG() for 4.3.

This seems like the most reasonable approach for now.  I see no reason
why we shouldn't be able to remove DEBUG from the chain leading to
ndr.h, while still keeping it available for OpenChange.  It seems to me
that the situation with RPC server modules is far, far better than the
situation for VFS module writers, where we don't even try and provide an
build without a full samba source tree.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




More information about the samba-technical mailing list