Thread (1 message) 1 message, 1 author, 2016-09-19
  • (off-list ancestor, not in this archive)
  • Re: VERBOSE flags · Dalessandro, Dennis <hidden> · 2016-09-19

Re: VERBOSE flags

From: Dalessandro, Dennis <hidden>
Date: 2016-09-19 12:29:43

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.  
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. 
quoted
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�{.n�+�������+%��lzwm��b�맲��r��zX��ݙ�����ܨ}���Ơz�&j:+v����n�r��6;靫3��\
nnX��f�z��2�ޙ���&�)ߡ�a����
�G���h��j:+v���w�٥
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help