[PATCHES] Logging to multiple debug backends

[Martin Schwenke]

On Tue, 17 Mar 2015 16:27:05 -0700, Christof Schmitt <cs at samba.org>
wrote:

> On Tue, Mar 17, 2015 at 09:06:52PM +1100, Martin Schwenke wrote:
> > On Tue, 17 Mar 2015 10:31:41 +0100, Volker Lendecke
> > <Volker.Lendecke at SerNet.DE> wrote:
> > 
> > > On Mon, Mar 16, 2015 at 01:54:26PM -0700, Christof Schmitt wrote:
> > > > I started implementing a separate array, see the attached patch. So far
> > > > it compiles, but it is untested. Does that fit your idea?
> > > 
> > > Ooops. Sorry, I did not mean this as a serious suggestion. I
> > > really doubt we will ever see this in profiles, because most
> > > of the filtering load is already done in the DEBUG macro. We
> > > only end up here if we have something to print, and any
> > > snprintf load or even write(2) calls will completely
> > > overwhelm this. If at one point we have dozens of backends
> > > compiled in, we will need to do something, but I think a
> > > typical configuration will have at most 4 compiled in at
> > > all.
> > > 
> > > I would rather have liked Martin to squash my arguments :-)
> > 
> > Yeah, yeah...  :-)
> > 
> > After I sent that email I did actually think about the locality of
> > reference issue with a linked list.  However, I wanted to see what
> > others thought.  When you replied I did think it was potential
> > over-engineering and whether we'd see any benefit.  :-)
> > 
> > Sorry, Christof... I also didn't mean to waste your time.  :-(
> 
> No worries, we can agree that this would be over-engineering :-)
> 
> > One thing the linked list gives you is some help in simplifying the
> > struct and API as I suggested.  There are various hacks I can think of
> > but none of them are elegant.
> > 
> > I still think the changes in the other 1/2 of the thread (ability to
> > pass options, changing API) are worthwhile.  I'll try to reply to that
> > soon...  and come up with something pretty for the API/struct thing.
> 
> I assume that you are trying to get the code ready for moving some of
> the ctdb logging backends. Since this is only an API internal to
> debug.c, we can change that anytime. I would propose that we agree on a
> format used in the 'logging' parameter for passing additional options,
> and make sure that we don't need to change that format going forward.
> Then we could work towards getting the current patch set in master.
> 
> Moving the ctdb logging backends can be done later. As the required
> changes are only internal to debug.c, we can do that at any time.
> 
> Does this sound like a plan?

Yes.  :-)

peace & happiness,
martin