On Mon, Sep 19, 2016 at 01:34:39PM +0000, Dalessandro, Dennis wrote:
> On Mon, 2016-09-19 at 16:25 +0300, Leon Romanovsky wrote:
> > On Mon, Sep 19, 2016 at 12:29:43PM +0000, Dalessandro, Dennis wrote:
> > > On Mon, 2016-09-19 at 09:15 +0300, Leon Romanovsky wrote:
> > > > The function pointers will cause us to create two similar
> > > > functions
> > > > (debug/regular) for every important function. It will leave to
> > > > code
> > > > duplication and/or introducing of new code to fill additional
> > > > fields
> > > > in returns to debug functions, so they will be able to print it.
> > >
> > > I do sort of like Doug's idea. It means you can easily instrument
> > > the
> > > heck out of a routine and have it always available. It provides
> > > more
> > > flexibility in what you can do in a debug version.
> > >
> > > You do make a valid point though about duplicating code. Perhaps
> > > that
> > > can be alleviated to some extent just by refactoring and adding
> > > inlines, etc.  
> >
> > At the end, we will invent tracepoints :)
> >
> > >
> > > > I wanted to propose to use tracepoints to provide debug
> > > > information
> > > > in
> > > > data paths. The tracepoints infrastructure uses hooks in the code
> > > > with
> > > > minimal impact on performance.
> > >
> > > This is so far the path we have chosen for hfi1. We have a number
> > > of
> > > tracepoints in various parts of the code. Again it's available on
> > > demand without special kernels or boot/driver options. 
> >
> > CONFIG_SDMA_VERBOSITY ????
>
> Yes we do have that, which illustrates that trace points can not do
> everything. I had hoped to deprecate that at some point. Regardless,
> sometimes you want additional code to be added or to do something
> slightly different. You can't do that with a tracepoint.

Can you elaborate more on this topic? Which limitations did you see
in tracepoints?

In regards of other discussion in KS 2016, "tracepoints and ABI
stability warranties" [1]. Are you strict with this tracepoints ABI?

>
> You can see we use tracepoints pretty extensively and that is our main
> vehicle for debugging. Here is where all the definitions are:
>
> $ ls trace_*
> trace_ctxts.h  trace_dbg.h  trace_ibhdrs.h  trace_misc.h  trace_rc.h  t
> race_rx.h  trace_tx.h

+1 :)

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-September/003850.html