lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <u2y912ec82a1003302242sb4f1ac2arb9c464d35993b7a1@mail.gmail.com>
Date:	Wed, 31 Mar 2010 08:42:02 +0300
From:	Neshama Parhoti <pneshama@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: pr_* versus dev_*

On Tue, Mar 30, 2010 at 7:52 PM, Joe Perches <joe@...ches.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
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ