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 ????

>
> > > 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