Re: VERBOSE flags

["Dalessandro, Dennis" <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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.

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

-Denny

> > 
> > > > Then we can drop the CONFIG_*_DEBUG options out of all of the
> > > > drivers.  That would be my preference.  I don't want any
> > > > compile
> > > > time
> > > > options because you never will be running a debug kernel when
> > > > you
> > > > need
> > > > it.  Per device, run time selectable so that you get 0 overhead
> > > > in
> > > > the
> > > > normal case is what I would like to see.
> > > 
> > > Great,
> > > We are aligned on this point, so do I. I see no reason in special
> > > compiled
> > > kernel or global module parameter to print debug prints for whole
> > > driver.
> > 
> > Same here.
> > 
> > -Denny