printk or pr_<level>?

[Raphael Silva]

Hi guys,

Thanks for the help, I learned a lot of new things.

On 7/23/14, 8:00 PM, Greg KH wrote:
> 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