[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL2PR07MB2306937C8C495DB80DA776CA8DFE0@BL2PR07MB2306.namprd07.prod.outlook.com>
Date: Tue, 13 Sep 2016 07:18:01 +0000
From: "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To: Leon Romanovsky <leon@...nel.org>,
Yuval Mintz <Yuval.Mintz@...gic.com>
CC: Mark Bloch <markb@...lanox.com>,
Ram Amrani <Ram.Amrani@...gic.com>,
"dledford@...hat.com" <dledford@...hat.com>,
David Miller <davem@...emloft.net>,
Ariel Elior <Ariel.Elior@...gic.com>,
Michal Kalderon <Michal.Kalderon@...gic.com>,
Rajesh Borundia <rajesh.borundia@...gic.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [RFC 02/11] Add RoCE driver framework
>> >> +uint debug;
>> >> +module_param(debug, uint, 0);
> >>> +MODULE_PARM_DESC(debug, "Default debug msglevel");
>>
>> >Why are you adding this as a module parameter?
>>
>> I believe this is mostly to follow same line as qede which also defines
> > 'debug' module parameter for allowing easy user control of debug
> > prints [& specifically for probe prints, which can't be controlled
> > otherwise].
> Can you give us an example where dynamic debug and tracing infrastructures
> are not enough?
> AFAIK, most of these debug module parameters are legacy copy/paste
> code which is useless in real life scenarios.
Define 'enough'; Using dynamic debug you can provide all the necessary
information and at an even better granularity that's achieved by suggested
infrastructure, but is harder for an end-user to use. Same goes for tracing.
The 'debug' option provides an easy grouping for prints related to a specific
area in the driver.
Powered by blists - more mailing lists