Commit 6e099f55 authored by Dan Streetman's avatar Dan Streetman Committed by Linus Torvalds

Documentation: expand/clarify debug documentation

The pr_debug() and related debug print macros all differ from the normal
pr_XXX() macros, in that the normal ones print unconditionally, while
the debug macros are compiled out unless DEBUG is defined or
CONFIG_DYNAMIC_DEBUG is set.  This isn't obvious, and the only way to
find this out is either to review the actual printk.h code or to read
CodingStyle, and the message there doesn't highlight the fact.

Change Documentation/CodingStyle to clearly indicate that pr_debug() and
related debug printing macros behave differently than all other pr_XXX()
macros, and attempt to clarify when and where the different debug
printing methods might be used.

Add short comment to printk.h above the pr_XXX() macros indicating that
while these macros print unconditionally, pr_debug() does not.
Signed-off-by: default avatarDan Streetman <ddstreet@ieee.org>
Cc: Joe Perches <joe@perches.com>
Cc: Fabian Frederick <fabf@skynet.be>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 6d9bcb62
...@@ -660,15 +660,23 @@ There are a number of driver model diagnostic macros in <linux/device.h> ...@@ -660,15 +660,23 @@ There are a number of driver model diagnostic macros in <linux/device.h>
which you should use to make sure messages are matched to the right device which you should use to make sure messages are matched to the right device
and driver, and are tagged with the right level: dev_err(), dev_warn(), and driver, and are tagged with the right level: dev_err(), dev_warn(),
dev_info(), and so forth. For messages that aren't associated with a dev_info(), and so forth. For messages that aren't associated with a
particular device, <linux/printk.h> defines pr_debug() and pr_info(). particular device, <linux/printk.h> defines pr_notice(), pr_info(),
pr_warn(), pr_err(), etc.
Coming up with good debugging messages can be quite a challenge; and once Coming up with good debugging messages can be quite a challenge; and once
you have them, they can be a huge help for remote troubleshooting. Such you have them, they can be a huge help for remote troubleshooting. However
messages should be compiled out when the DEBUG symbol is not defined (that debug message printing is handled differently than printing other non-debug
is, by default they are not included). When you use dev_dbg() or pr_debug(), messages. While the other pr_XXX() functions print unconditionally,
that's automatic. Many subsystems have Kconfig options to turn on -DDEBUG. pr_debug() does not; it is compiled out by default, unless either DEBUG is
A related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to the defined or CONFIG_DYNAMIC_DEBUG is set. That is true for dev_dbg() also,
ones already enabled by DEBUG. and a related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to
the ones already enabled by DEBUG.
Many subsystems have Kconfig debug options to turn on -DDEBUG in the
corresponding Makefile; in other cases specific files #define DEBUG. And
when a debug message should be unconditionally printed, such as if it is
already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be
used.
Chapter 14: Allocating memory Chapter 14: Allocating memory
......
...@@ -210,6 +210,12 @@ extern asmlinkage void dump_stack(void) __cold; ...@@ -210,6 +210,12 @@ extern asmlinkage void dump_stack(void) __cold;
#define pr_fmt(fmt) fmt #define pr_fmt(fmt) fmt
#endif #endif
/*
* These can be used to print at the various log levels.
* All of these will print unconditionally, although note that pr_debug()
* and other debug macros are compiled out unless either DEBUG is defined
* or CONFIG_DYNAMIC_DEBUG is set.
*/
#define pr_emerg(fmt, ...) \ #define pr_emerg(fmt, ...) \
printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__) printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
#define pr_alert(fmt, ...) \ #define pr_alert(fmt, ...) \
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment