Joe, Jim, Jason, Joe's conversion of mac80211 to pr_debug() was pretty much a disaster, now people have to first select what they want in Kconfig, and then still enable dynamic debug in debugfs... That doesn't make any sense at all, and requires teaching everybody new tricks, so I'm basically reverting it for now in favour of pr_info() instead of pr_debug(). I'd actually not mind using pr_debug() if it meant we could get rid of all the Kconfig symbols, but that's not possible. The biggest problem here really is that the dynamic debug infrastructure lets us enable messages at runtime, which is great, but the granularity is useless since you only have these possibilities: * module name * file name * function name * line number * format string match The module is obviously way too broad for most modules, and the others are way too fine-grained. To actually make it useful, there needs to be a "key" that you can use, e.g. in mac80211 I could do DECLARE_DYNDBG_KEY(ps); and in some C file, I'd have to do the matching DEFINE_DYNDBG_KEY(ps), similar to how tracing works. Then, I would get * an inline function ps_dbg() * a macro "is_ps_debug" or so, so that you can use the enable/disable bit of this key, say to create wrappers like netdev_ps_dbg (probably needs to be a macro if it uses jump labels which it should I think) and probably some other magic. The DEFINE_ macro would create some structure, and that would go into some special module section, so that then the dyn debug core can collect all these keys and allow us to do something like echo mac80211:ps > dynamic_debug/control That would actually allow us to get rid of all our own Kconfig symbols and would allow a lot of drivers to get rid of their own infrastructure for enabling/disabling certain "log levels" etc... johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
