Samba DEBUG in OpenChange

[Andrew Bartlett]

On Sun, 2015-12-13 at 13:10 +0000, Jelmer Vernooij wrote:
> On Sat, Dec 12, 2015 at 05:51:05PM -0800, Jeremy Allison wrote:
> > 
> See
> https://raw.githubusercontent.com/openchange/openchange/master/doc/de
> veloper/logging.txt
> for the current plan.
> 
> We need an override for DEBUG on a per-NDR and per DCE/RPC-server
> context basis ideally.
> 
> A global override for the DEBUG functions means that output from
> *all*
> DEBUG() calls will be redirected, not just those related to
> OpenChange
> DCE/RPC calls. OpenChange (currently) loads into the samba server,
> meaning all logging (even for lsa, samr, etc) would go to the
> OpenChange logs when OpenChange is loaded.
> 
> > Why not just replace these functions calls with
> > ones that go through a global vector that can be
> > overwritten.
> > 
> > On startup Samba writes in the functions it uses
> > (dbgtext() and friends) and OpenChange writes in
> > it's functions.
> This adds an extra level of indirection in Samba, but it exposes the
> same number of internals (debugtext() and friends) to the outside
> world. From the Samba perspective, I don't see how this is an
> improvement over the previous situation where debugtext() et al were
> public and called directly by OpenChange.

My biggest concern in this thread is letting the perfect get in the way
of the good.  DEBUG() has, as an API, been essentially unchanged in
Samba for the entire 15 years I've been involved.  We extend it a
little from time to time but at a API level it is pretty set in stone,
because of how much code we have that uses it.

Why not just make that public again, then work on the improvements.  If
we really need to, we certainly can still innovate on the helper
functions under DEBUG(), but that isn't likely (due to our own massive
use) to break the API.  (And OpenChange has said their primary concern
is the API, not ABI, and we wouldn't be doing that during a release
stream in any case).

Can't we just get this back to where we were in 4.1, fix the regression
in 4.2 before it leaves maintenance, allow OpenChagne to build again,
and then look for future ideas for 4.4 or 4.5?  

The problem with the 'devise the perfect solution' tack is that we
won't likely get it sorted, and used on both sides, until after 4.4 has
branched (January 26), and that is a long time to leave OpenChange
swinging in the breeze. 

Thanks,

Andrew Bartlett

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151214/4c8afa88/signature.sig>