motivation behind pr_xxx macros
While writing some code on 2.6.32, I have come across some of these macros that in turn call printk: pr_emerg pr_alert ... pr_debug Is there any case when should these macros be preferred over explicit printk statements? What is the motivation behind providing these macros when this task can already be accomplished by using printk statements explicitly with priority levels? Regards, Himanshu
While writing some code on 2.6.32, I have come across some of these macros that in turn call printk: pr_emerg pr_alert ... pr_debug Is there any case when should these macros be preferred over explicit printk statements? What is the motivation behind providing these macros when this task can already be accomplished by using printk statements explicitly with priority levels? Regards, Himanshu
Hi.... On Sun, Jan 30, 2011 at 22:11, Himanshu Aggarwal <lkml.himanshu@gmail.com> wrote:
While writing some code on 2.6.32, I have come across some of these macros that in turn call printk:
pr_emerg pr_alert ... pr_debug
Is there any case when should these macros be preferred over explicit printk statements?
I personally think it's a matter of "putting another layer of abstraction". That way, if somehow the definition of...let's "emerg" facility differ, you don't need to change the whole code. Just edit the pr_emerg and you're back into the game. IIRC too, it might have something to do with dynamic printk activation...something like "ok I need to turn that, that and that printk...on...". So to ease that thing, wrapper is created ...and it decide what it has to do when printk() is enabled or not. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Sun, Jan 30, 2011 at 08:41:14PM +0530, Himanshu Aggarwal wrote:
While writing some code on 2.6.32, I have come across some of these macros that in turn call printk:
pr_emerg pr_alert ... pr_debug
Is there any case when should these macros be preferred over explicit printk statements?
Yes, for almost all usages, use them instead of printk().
What is the motivation behind providing these macros when this task can already be accomplished by using printk statements explicitly with priority levels?
It forces you to actually specify a level (which people sometimes forget) and it ties you into the dynamic debugging logic (with the pr_debug() call) and it provides a common prefix specifying your exact module that is creating the output. But even better, please use the dev_* functions instead, whereever you have access to a struct device * as that uniquely identifies both your module, and your device, in a standard way that userspace can understand, and it ties into the dynamic debugging infrastructure as well. But for those few places where you don't have a struct device *, use the pr_* functions instead please and not "raw" printk() calls. Hope this helps, greg k-h
participants (3)
-
Greg KH -
Himanshu Aggarwal -
Mulyadi Santosa