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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
