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
Attachment:
signature.asc
Description: PGP signature
