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