All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: motivation behind pr_xxx macros
Date: Sun, 30 Jan 2011 13:35:29 -0800	[thread overview]
Message-ID: <20110130213529.GA25128@kroah.com> (raw)
In-Reply-To: <AANLkTikMXMU7y=gQRGsDxzpuGm4taLjRFCORoQcRW2+Y@mail.gmail.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

      parent reply	other threads:[~2011-01-30 21:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-30 15:11 motivation behind pr_xxx macros Himanshu Aggarwal
2011-01-30 15:12 ` Himanshu Aggarwal
2011-01-30 18:19 ` Mulyadi Santosa
2011-01-30 21:35 ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110130213529.GA25128@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.