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