On Wed, 2014-05-07 at 10:35 -0400, Steven Rostedt wrote: > On Wed, 7 May 2014 10:21:28 -0400 Dan Streetman <ddstr...@ieee.org> wrote:
> > It would be even better if the note could clarify that sometimes it is > > ok to use printk(KERN_DEBUG > > Exactly. I think it's rather stupid to have to do a #define DEBUG to > have pr_debug() print in general. > > I see no reason to have pr_debug() be anything different than the other > pr_*() functions. pr_debug is meant to be disabled and have _no_ runtime effect unless DEBUG is #defined. For embedded systems where printk is enabled, pr_debug does have some utility for code/text reduction and it can have a minor impact on performance. tracing is frequently a better option for development and is often a better runtime tool. CONFIG_DYNAMIC_DEBUG is not enabled by default in most defconfigs. The _only_ reason it's possible is because dynamic debug is runtime patched to be fairly cost free for relatively larger memory/higher performance systems. > The plist code is a perfect scenario where printk(KERN_DEBUG...) is > appropriate, and using pr_debug() with a hard coded #define DEBUG is > just stupid. yup. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
