* printk or pr_<level>?
@ 2014-07-23 18:16 Raphael Silva
2014-07-23 18:34 ` Kristofer Hallin
0 siblings, 1 reply; 10+ messages in thread
From: Raphael Silva @ 2014-07-23 18:16 UTC (permalink / raw)
To: kernelnewbies
Hello guys,
1)
If I use printk(KERN_<LEVEL>...) the checkpatch warns me:
WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then
dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ...
So, pr_devel() is the correct way to print a debug level msg?
2)
if pr_<level> is the correct way, what about KERN_DEFAULT ?
If I don't put the kern_level (printk("Hello");)
WARNING: printk() should include KERN_ facility level
if I put KERN_DEFAULT:
WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then
dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ...
But for KERN_DEFAULT, there isn't a macro pr_<level> like pr_devel().
Can anyone show me the correct way?
tks
^ permalink raw reply [flat|nested] 10+ messages in thread* printk or pr_<level>? 2014-07-23 18:16 printk or pr_<level>? Raphael Silva @ 2014-07-23 18:34 ` Kristofer Hallin 2014-07-23 18:39 ` Fernando Apesteguía 2014-07-23 21:45 ` Arlie Stephens 0 siblings, 2 replies; 10+ messages in thread From: Kristofer Hallin @ 2014-07-23 18:34 UTC (permalink / raw) To: kernelnewbies 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. 2. Use pr_debug. On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva <raphaelcampos.rp@gmail.com> wrote: > Hello guys, > > 1) > If I use printk(KERN_<LEVEL>...) the checkpatch warns me: > WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then > dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... > > So, pr_devel() is the correct way to print a debug level msg? > > 2) > if pr_<level> is the correct way, what about KERN_DEFAULT ? > > If I don't put the kern_level (printk("Hello");) > WARNING: printk() should include KERN_ facility level > > if I put KERN_DEFAULT: > WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then > dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... > > But for KERN_DEFAULT, there isn't a macro pr_<level> like pr_devel(). > > Can anyone show me the correct way? > > tks > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 18:34 ` Kristofer Hallin @ 2014-07-23 18:39 ` Fernando Apesteguía 2014-07-23 18:40 ` Kristofer Hallin 2014-07-23 21:45 ` Arlie Stephens 1 sibling, 1 reply; 10+ messages in thread From: Fernando Apesteguía @ 2014-07-23 18:39 UTC (permalink / raw) To: kernelnewbies On Wed, Jul 23, 2014 at 8:34 PM, Kristofer Hallin < kristofer.hallin@gmail.com> 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. > By default, pr_debug is an empty macro unless you add -DDEBUG to CFLAGS. So in addition to what Kristofer said, be sure you compile your module/kernel with that flag enabled. Cheers. > > 2. Use pr_debug. > > On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva > <raphaelcampos.rp@gmail.com> wrote: > > Hello guys, > > > > 1) > > If I use printk(KERN_<LEVEL>...) the checkpatch warns me: > > WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then > > dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... > > > > So, pr_devel() is the correct way to print a debug level msg? > > > > 2) > > if pr_<level> is the correct way, what about KERN_DEFAULT ? > > > > If I don't put the kern_level (printk("Hello");) > > WARNING: printk() should include KERN_ facility level > > > > if I put KERN_DEFAULT: > > WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then > > dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... > > > > But for KERN_DEFAULT, there isn't a macro pr_<level> like pr_devel(). > > > > Can anyone show me the correct way? > > > > tks > > > > > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140723/4ca278c5/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 18:39 ` Fernando Apesteguía @ 2014-07-23 18:40 ` Kristofer Hallin 2014-07-23 18:56 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Kristofer Hallin @ 2014-07-23 18:40 UTC (permalink / raw) To: kernelnewbies Yes. https://www.kernel.org/doc/local/pr_debug.txt On Wed, Jul 23, 2014 at 8:39 PM, Fernando Apestegu?a <fernando.apesteguia@gmail.com> wrote: > > > > On Wed, Jul 23, 2014 at 8:34 PM, Kristofer Hallin > <kristofer.hallin@gmail.com> 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. > > > By default, pr_debug is an empty macro unless you add -DDEBUG to CFLAGS. So > in addition to what Kristofer said, be sure you compile your module/kernel > with that flag enabled. > > Cheers. > >> >> >> 2. Use pr_debug. >> >> On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva >> <raphaelcampos.rp@gmail.com> wrote: >> > Hello guys, >> > >> > 1) >> > If I use printk(KERN_<LEVEL>...) the checkpatch warns me: >> > WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then >> > dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... >> > >> > So, pr_devel() is the correct way to print a debug level msg? >> > >> > 2) >> > if pr_<level> is the correct way, what about KERN_DEFAULT ? >> > >> > If I don't put the kern_level (printk("Hello");) >> > WARNING: printk() should include KERN_ facility level >> > >> > if I put KERN_DEFAULT: >> > WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then >> > dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... >> > >> > But for KERN_DEFAULT, there isn't a macro pr_<level> like pr_devel(). >> > >> > Can anyone show me the correct way? >> > >> > tks >> > >> > >> > >> > >> > _______________________________________________ >> > Kernelnewbies mailing list >> > Kernelnewbies at kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 18:40 ` Kristofer Hallin @ 2014-07-23 18:56 ` Greg KH 0 siblings, 0 replies; 10+ messages in thread From: Greg KH @ 2014-07-23 18:56 UTC (permalink / raw) To: kernelnewbies On Wed, Jul 23, 2014 at 08:40:04PM +0200, Kristofer Hallin wrote: > Yes. > > https://www.kernel.org/doc/local/pr_debug.txt No, that isn't true if CONFIG_DYNAMIC_DEBUG is enabled, which you really should enable all the time. If that option is enabled, then you can enable the debugging messages after the code is loaded, or from the module load command line, through that interface, which is much more useful than just "enable/disable at build time". Hope this helps, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 18:34 ` Kristofer Hallin 2014-07-23 18:39 ` Fernando Apesteguía @ 2014-07-23 21:45 ` Arlie Stephens 2014-07-23 23:00 ` Greg KH 1 sibling, 1 reply; 10+ messages in thread From: Arlie Stephens @ 2014-07-23 21:45 UTC (permalink / raw) To: kernelnewbies 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. 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... > > 2. Use pr_debug. > > On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva > <raphaelcampos.rp@gmail.com> wrote: > > Hello guys, > > > > 1) > > If I use printk(KERN_<LEVEL>...) the checkpatch warns me: > > WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then > > dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... > > > > So, pr_devel() is the correct way to print a debug level msg? > > > > 2) > > if pr_<level> is the correct way, what about KERN_DEFAULT ? > > > > If I don't put the kern_level (printk("Hello");) > > WARNING: printk() should include KERN_ facility level > > > > if I put KERN_DEFAULT: > > WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then > > dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... > > > > But for KERN_DEFAULT, there isn't a macro pr_<level> like pr_devel(). > > > > Can anyone show me the correct way? > > > > tks -- Arlie (Arlie Stephens arlie at worldash.org) ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 21:45 ` Arlie Stephens @ 2014-07-23 23:00 ` Greg KH 2014-07-23 23:00 ` Greg KH 2014-07-24 18:36 ` Arlie Stephens 0 siblings, 2 replies; 10+ messages in thread From: Greg KH @ 2014-07-23 23:00 UTC (permalink / raw) To: kernelnewbies 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. So there is a method to this madness, and it is pretty simple if you think about it this way. Does that help out? greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 23:00 ` Greg KH @ 2014-07-23 23:00 ` Greg KH 2014-07-24 0:02 ` Raphael Silva 2014-07-24 18:36 ` Arlie Stephens 1 sibling, 1 reply; 10+ messages in thread From: Greg KH @ 2014-07-23 23:00 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 23:00 ` Greg KH @ 2014-07-24 0:02 ` Raphael Silva 0 siblings, 0 replies; 10+ messages in thread From: Raphael Silva @ 2014-07-24 0:02 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* printk or pr_<level>? 2014-07-23 23:00 ` Greg KH 2014-07-23 23:00 ` Greg KH @ 2014-07-24 18:36 ` Arlie Stephens 1 sibling, 0 replies; 10+ messages in thread From: Arlie Stephens @ 2014-07-24 18:36 UTC (permalink / raw) To: kernelnewbies Thank-you Greg On Jul 23 2014, 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? [snip] > 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. > > So there is a method to this madness, and it is pretty simple if you > think about it this way. > > Does that help out? Yes it does. Thank you. And I think I see why I needed help - I'm mentally a "core kernel" person, whatever I may happen to be working on at the moment ;-) So my archetypal kernel message would be something like the ones generated by BUG_ON() ;-) > > greg k-h -- Arlie (Arlie Stephens arlie at worldash.org) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-07-24 18:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-23 18:16 printk or pr_<level>? Raphael Silva 2014-07-23 18:34 ` Kristofer Hallin 2014-07-23 18:39 ` Fernando Apesteguía 2014-07-23 18:40 ` Kristofer Hallin 2014-07-23 18:56 ` Greg KH 2014-07-23 21:45 ` Arlie Stephens 2014-07-23 23:00 ` Greg KH 2014-07-23 23:00 ` Greg KH 2014-07-24 0:02 ` Raphael Silva 2014-07-24 18:36 ` Arlie Stephens
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).