Samba DEBUG in OpenChange
abartlet at samba.org
Mon Dec 14 02:27:47 UTC 2015
On Sun, 2015-12-13 at 21:00 -0500, Simo wrote:
> 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/do
> > > c/
> > > 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.
To be clear, it was public. We broke that promise. Perhaps it
shouldn't have been made, and the OpenChange folks are only asking for
the API to be kept. I also think that it is a false choice that public
APIs need to be never-ever-changed ABIs, this all worked quite fine
until it was unilaterally removed.
We are using our bad experience with providing poorly controlled ABIs
to general audiences in the past to justify entirely yanking another
one to a specific sister project without solving the needs *first*. I
don't think that's reasonable.
> > 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
> issue for years, we need to get to a resolution, going back is not
> really fair.
Who isn't it fair to? To those who removed DEBUG() from the public
> > 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
> API. The NDR marshalling has been mentioned, but that stuff is
> not interesting for logging to users only for developers, and I guess
> developers can read 2 separate files ? (The samba log for the ndr
> debugs and the openchange log for everything else ?)
I'm no openchange dev, and perhaps that would be fine, but that still
needs DEBUG() back public again (NDR code regularly uses primitives
provided by libndr).
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
More information about the samba-technical