[PATCH] New debug backend "ringbuf"

Ralph Böhme slow at samba.org
Thu Jan 19 10:48:17 UTC 2017


On Thu, Jan 19, 2017 at 09:39:34PM +1100, Andrew Bartlett wrote:
> On Thu, 2017-01-19 at 11:31 +0100, Ralph Böhme wrote:
> > On Thu, Jan 19, 2017 at 10:10:06AM +0100, Ralph Böhme wrote:
> > > On Thu, Jan 19, 2017 at 10:07:06AM +0100, Volker Lendecke wrote:
> > > > On Thu, Jan 19, 2017 at 09:07:28AM +0100, Ralph Böhme wrote:
> > > > > On Mon, Jan 09, 2017 at 10:45:01PM +0100, Ralph Böhme wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > On Mon, Jan 09, 2017 at 10:16:01PM +0100, Ralph Böhme wrote:
> > > > > > > On Tue, Jan 10, 2017 at 10:09:31AM +1300, Andrew Bartlett
> > > > > > > wrote:
> > > > > > > > Can you register it in source4/lib/messaging.c as well,
> > > > > > > > so we can ask a
> > > > > > > > 'samba' process the same question?
> > > > > > > 
> > > > > > > sure, updated patchset on the way...
> > > > > > 
> > > > > > here we go.
> > > > > 
> > > > > *ping*
> > > > > 
> > > > > Anyone time for a review? Thanks!
> > > > 
> > > > This mixes the messaging.idl changes with the pure debug ringbuf.
> > > > I
> > > > know that it's a bit hairy to get the messaging types right, but
> > > > is
> > > > there a strict reason why MSG_RINGBUF_LOG can't be assigned
> > > > manually?
> > > 
> > > the only reason was that I hesitating finding a free slot and
> > > choosing a value.
> > > 
> > > I can surely split that up and assing manually. Afaict the only
> > > reason values
> > > are acutally assigned manually is that pidl doesn't support mixing
> > > automatic
> > > enumeration with direct assignment.
> > 
> > ok, so here is a ringbuf only patchset. I'll post the pidl enum stuff
> > in a new thread.
> 
> Thanks.
> 
> > Fwiw, I didn't bother reordering the ringbuf to present a strictly
> > chronological
> > increasing log as that just complicates the code in a subsystem that
> > is meant to
> > be the last ressort when hunting certain bugs. It really should be
> > simple and
> > bugfree itself without any sophisticated internal state.
> 
> In what sense is it not chronological?  Just that the wrap-around might
> mean new entries could start anywhere in the buffer?

yes, like this for a ringbuf with 4 slots:

5
6
3
4

where 3 is the oldest message and 5 is the newest one, 1 and 2 were overwritten
by 5 and 6.

Cheerio!
-slow



More information about the samba-technical mailing list