Samba DEBUG in OpenChange

[Simo]

On Mon, 2015-12-14 at 14:38 +1300, Andrew Bartlett wrote:
> 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.

To make it public we'd rather need a stable ABI, and the ABI has not
been stable for so long.

> 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?  

I think one problem with this plan is that we've been dancing with this
issue for years, we need to get to a resolution, going back is not
really fair.

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

What I do not get is what prevents openchange from providing their own
API. The NDR marshalling has been mentioned, but that stuff is usually
not interesting for logging to users only for developers, and I guess
developers can read 2 separate files ? (The samba log for the ndr level
debugs and the openchange log for everything else ?) 

Maybe I am missing something though.

Simo.