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