motivation behind pr_xxx macros

motivation behind pr_xxx macros

[Himanshu Aggarwal]

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

motivation behind pr_xxx macros

[Himanshu Aggarwal]

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

motivation behind pr_xxx macros

[Mulyadi Santosa]

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

motivation behind pr_xxx macros

[Greg KH]

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