pr_* versus dev_*

pr_* versus dev_*

[Neshama Parhoti]

Which set of macros should I use in my driver ?

pr_info, pr_err, etc...  or dev_info, dev_err,    etc. ?

what are the advantages of the dev_* macros over the pr_* macros
(why does it take the device pointer as an argument) ?

obviously I don't have access to my device pointer in all my functions..
so pr_info is easier to use..
but if it's wanted, obviously I can arrange to have my device pointer
accessible..

thank you
~pnesh

Re: pr_* versus dev_*

[Joe Perches]

On Tue, 2010-03-30 at 19:07 +0300, Neshama Parhoti wrote:
> Which set of macros should I use in my driver ?
> 
> pr_info, pr_err, etc...  or dev_info, dev_err,    etc. ?

Possibly all of them.

> what are the advantages of the dev_* macros over the pr_* macros
> (why does it take the device pointer as an argument) ?
> 
> obviously I don't have access to my device pointer in all my functions..
> so pr_info is easier to use..
> but if it's wanted, obviously I can arrange to have my device pointer
> accessible..

You should also use dev_<level> where possible.
You should also use netdev_<level> and netif_<level> if your
device is a networking driver.
You should #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
to have a standard prefix for your driver.

Function	Benefit

pr_<level>:	Slightly shorter than printk(KERN_<LEVEL>)
		Gets a standard prefix with pr_fmt
dev_<level>:	Standardized device information:
		dev_driver_string, then dev_name
		dev_driver_string is the device's driver's name
		if it is bound to a device.  If the device is not
		bound to a device, the name of the bus it is
		attached to.  If it is not attached to a bus but
		has a class, the class name.
		If no class, you'll find an empty dance card.
netdev_<level>:	Appends struct net_device.name to dev_<level> prefix
		Use dev_<level> until alloc_netdev or alloc_etherdev
		has been called successfully.
netif_<level>:	Test network interface message level (netif_msg_<foo>)
		before calling netdev_<level>

Message logging with KERN_DEBUG levels are a bit more complicated:

These calls are optimized away and never printed unless
DEBUG is #defined or CONFIG_DYNAMIC_DEBUG is enabled.

pr_debug
dev_dbg
netdev_dbg
netif_dbg

To always have these emitted, use the appropriate printk calls

printk(KERN_DEBUG	this does not get a standard prefix
			use printk(KERN_DEBUG pr_fmt(fmt) if desired
dev_printk(KERN_DEBUG
netdev_printk(KERN_DEBUG
netif_printk(priv, msg, KERN_DEBUG

There are  _vdbg variants for even more verbose output if
VERBOSE_DEBUG is #defined.

Re: pr_* versus dev_*

[Neshama Parhoti]

On Tue, Mar 30, 2010 at 7:52 PM, Joe Perches <joe@perches.com> wrote:
> On Tue, 2010-03-30 at 19:07 +0300, Neshama Parhoti wrote:
>> Which set of macros should I use in my driver ?
>>
>> pr_info, pr_err, etc...  or dev_info, dev_err,    etc. ?
>
> Possibly all of them.
>
>> what are the advantages of the dev_* macros over the pr_* macros
>> (why does it take the device pointer as an argument) ?
>>
>> obviously I don't have access to my device pointer in all my functions..
>> so pr_info is easier to use..
>> but if it's wanted, obviously I can arrange to have my device pointer
>> accessible..
>
> You should also use dev_<level> where possible.
> You should also use netdev_<level> and netif_<level> if your
> device is a networking driver.
> You should #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> to have a standard prefix for your driver.
>
> Function        Benefit
>
> pr_<level>:     Slightly shorter than printk(KERN_<LEVEL>)
>                Gets a standard prefix with pr_fmt
> dev_<level>:    Standardized device information:
>                dev_driver_string, then dev_name
>                dev_driver_string is the device's driver's name
>                if it is bound to a device.  If the device is not
>                bound to a device, the name of the bus it is
>                attached to.  If it is not attached to a bus but
>                has a class, the class name.
>                If no class, you'll find an empty dance card.
> netdev_<level>: Appends struct net_device.name to dev_<level> prefix
>                Use dev_<level> until alloc_netdev or alloc_etherdev
>                has been called successfully.
> netif_<level>:  Test network interface message level (netif_msg_<foo>)
>                before calling netdev_<level>
>
> Message logging with KERN_DEBUG levels are a bit more complicated:
>
> These calls are optimized away and never printed unless
> DEBUG is #defined or CONFIG_DYNAMIC_DEBUG is enabled.
>
> pr_debug
> dev_dbg
> netdev_dbg
> netif_dbg
>
> To always have these emitted, use the appropriate printk calls
>
> printk(KERN_DEBUG       this does not get a standard prefix
>                        use printk(KERN_DEBUG pr_fmt(fmt) if desired
> dev_printk(KERN_DEBUG
> netdev_printk(KERN_DEBUG
> netif_printk(priv, msg, KERN_DEBUG
>
> There are  _vdbg variants for even more verbose output if
> VERBOSE_DEBUG is #defined.

thank you.

so i should use whatever print call that adds most information right ?

even if that means that some part of the driver uses pr_* and some
part of the driver use dev_* ?

thank you again
>
>

Re: pr_* versus dev_*

[Joe Perches]

On Wed, 2010-03-31 at 08:42 +0300, Neshama Parhoti wrote:
> so i should use whatever print call that adds most information right ?

I think so.

> even if that means that some part of the driver uses pr_* and some
> part of the driver use dev_* ?

Yes.

Re: pr_* versus dev_*

[Neshama Parhoti]

On Wed, Mar 31, 2010 at 8:48 AM, Joe Perches <joe@perches.com> wrote:
> On Wed, 2010-03-31 at 08:42 +0300, Neshama Parhoti wrote:
>> so i should use whatever print call that adds most information right ?
>
> I think so.
>
>> even if that means that some part of the driver uses pr_* and some
>> part of the driver use dev_* ?
>
> Yes.
>
>

thank you !