On 10/18/2010 2:43 AM, Centelles, Sylvain wrote:
+       dev_dbg(&client->dev, "write reg:0x%x value:0x%x \n", reg, tmp);
this debug happens on EVERY write!
Please reserve debug prints only to places where something is going wrong ;(
Hi Arjan,
Well, let me ask something on this : I would have thought that we could use 
dev_dbg for debugging purpose, which is not always related to error conditions. 
In combination with dynamic printk, it can be a very usefull way of providing 
some diagnostic on a production phone (or nearly product...), just to 
understand what's going on on the target.
Do you really confirm that dbg traces must be reserved for errors? If so, can 
you explain why? (I thought there was no perf impact after the macro is 
stripped)

In order to do some diagnostics, I would even have wanted to put as much 
dev_dbg as possible in all critical areas of the code, where there is a lot of 
control complexity. This, combined with the dynamic debug feature behind the 
dev_dbg macros could be really helpful.

I had asked you the question on dynamic_printk some time ago, where you 
proposed to activate it by default if we found it to be working.
I did not follow up on this, because yes, it's working really fine, but it is 
using some hash tables  to determine if the log is enabled or not. So this may 
have impact on performance if there are widespread dev_dbg+ dynamic_printk 
enabled. I was planning to study the real perf impact before going back to you. 
But if we cannot use dev_dbg for anything else than errors, this study may be 
useless...

Unless you know another way to have dynamic tracing/diagnostic capability 
without recompiling the kernel?

there needs to be a balance.
random print's don't add diagnostic capability. well placed print's do.
if you put random dev_dbg()'s everywhere, instead you make the diagnostic capability completely zero.

and if something is really critical, put a trace point there, not a print...

_______________________________________________
Meego-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel

Reply via email to