printk or pr_<level>?

[greg@kroah.com (Greg KH)]

On Wed, Jul 23, 2014 at 04:00:04PM -0700, Greg KH wrote:
> On Wed, Jul 23, 2014 at 02:45:05PM -0700, Arlie Stephens wrote:
> > On Jul 23 2014, Kristofer Hallin wrote:
> > 
> > > 1. No. Depending on what subsystem your are printing logs from you
> > > should use different functions for logging. In the networking
> > > subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will
> > > always work and is always preferred over printk.
> > 
> > Why?  
> > 
> > No snark intended here, just confused curiousity. 
> > 
> > It would seem to me that one common method of printing would be better
> > than a different one for each subsystem, each needing to be
> > individually remembered, and potentially having its own
> > bugs\b\b\b\bquirks. 
> > 
> > The kernel is complex enough, without adding uneeded extra.
> 
> Yes it is, but it's "layered", in that normally you only deal with one
> specific layer.  Very rarely are you touching code everywhere in the
> kernel.
> 
> > And yes, this begs the question of why you want to print messages
> > from the kernel, whether they ought to be conditional and/or rate
> > limited, etc. etc.   Clearly the recommendation of pr_debug() suggests
> > someone thinks they should be at least somewhat conditional...
> 
> Ok, here's the rule in one sentance:
> 	Be as _descriptive_ as you can with the device that is emitting
> 	the message.
> 
> So what does that mean in reality?
> 
> Use the subsystem's logging macros for your messages.  If you are not in
> a subsystem, then fall back to the "default" pr_* messages.
> 
> So, if you are a network driver, then use netdev_dbg().  Other
> subsystems of "class" devices have their own form of logging macros, and
> they should be easy to find.
> 
> If you aren't in a class driver, but are a driver, then use dev_dbg(),
> because you do have a device pointer accessable to you (if you don't,
> either you are in your module init or exit function, and you shouldn't
> be printing messages then anyway.)
> 
> If you are not in a driver, and you do not have _any_ 'struct device'
> accessable to you, reconsider if you really want to be printing
> anything, as the use of it to a user is going to be really low.  But if
> you have to, then fall back to the pr_* functions, as those tie into the
> dynamic debugging logic of the kernel, and provide a format that is
> unified that userspace tools can use to hopefully search and find things
> properly.

Oh, and never use a "raw" printk() call anymore, someone will just come
along behind you and fix it up to use the "proper" macro, if you happen
to get it accepted into the kernel tree.

greg k-h