Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
On 03/04/2014 06:31 AM, yogesh wrote: > This patch adds documentation that clarifies the use of various > diagnostic printing messages. It shows the preference of subsystem_dbg > calls to dev_dbg (whenever possible), as they first preferred format of > logging debug messages. > Signed-off-by: Yogesh Chaudhari > --- > Documentation/CodingStyle | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > index 7fe0546..083f738 100644 > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > @@ -662,6 +662,23 @@ 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 > particular device, defines pr_debug() and pr_info(). > > +If the subsystem has its own diagnostic macros then they should be used > +instead of dev_dbg calls. > +e.g. If you are using network subsystem, use netdev_dbg; E.g., if you are > +if you are using V4L, use v4l_dbg etc. > +This standardises the output format in every subsystem. > + > +Depending on your changes, the following order of precedence > +applies to printing messages: > +1. [subsystem]_dbg() is preferred when the subsystem has its own > +diagnostic macros. > +2. dev_dbg() is preferred when you have a generic struct device object. > +3. pr_debug() should be used when 1 and 2 above are not applicable. > +4. printk() should be avoided. > + > +Note: The above order applies to diagnostic calls of all log levels viz: > +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. > + > 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 > messages should be compiled out when the DEBUG symbol is not defined (that > -- -- ~Randy -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
Hi, [+CC Rob] 2014-03-04 15:31 GMT+01:00 yogesh : > This patch adds documentation that clarifies the use of various > diagnostic printing messages. It shows the preference of subsystem_dbg > calls to dev_dbg (whenever possible), as they first preferred format of > logging debug messages. > Signed-off-by: Yogesh Chaudhari Acked-by: Levente Kurusa > --- > Documentation/CodingStyle | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > index 7fe0546..083f738 100644 > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > @@ -662,6 +662,23 @@ 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 > particular device, defines pr_debug() and pr_info(). > > +If the subsystem has its own diagnostic macros then they should be used > +instead of dev_dbg calls. > +e.g. If you are using network subsystem, use netdev_dbg; > +if you are using V4L, use v4l_dbg etc. > +This standardises the output format in every subsystem. > + > +Depending on your changes, the following order of precedence > +applies to printing messages: > +1. [subsystem]_dbg() is preferred when the subsystem has its own > +diagnostic macros. > +2. dev_dbg() is preferred when you have a generic struct device object. > +3. pr_debug() should be used when 1 and 2 above are not applicable. > +4. printk() should be avoided. > + > +Note: The above order applies to diagnostic calls of all log levels viz: > +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. > + > 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 > messages should be compiled out when the DEBUG symbol is not defined (that > -- > > Regards > Yogesh > [...] A lot better, but please next time send it as a separate mail with subject [PATCH v2] or something like that. Thanks! -- Regards, Levente Kurusa -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as they first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari --- Documentation/CodingStyle | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..083f738 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,23 @@ 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 particular device, defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when the subsystem has its own +diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() should be used when 1 and 2 above are not applicable. +4. printk() should be avoided. + +Note: The above order applies to diagnostic calls of all log levels viz: +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- Regards Yogesh On Tue, Mar 04, 2014 at 02:39:42PM +0100, Levente Kurusa wrote: > Hi, > > 2014-03-04 12:48 GMT+01:00 yogesh : > > This patch adds documentation that clarifies the use of various diagnostic > > printing messages. It shows the preference of subsystem_dbg calls to > > dev_dbg (whenever possible), as the first preferred format of logging debug > > messages. > > Please wrap your changelog at 80 characters a line. > > > Signed-off-by: Yogesh Chaudhari > > --- > > Documentation/CodingStyle | 14 ++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > > index 7fe0546..9e0de25 100644 > > --- a/Documentation/CodingStyle > > +++ b/Documentation/CodingStyle > > @@ -662,6 +662,20 @@ 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 > > particular device, defines pr_debug() and pr_info(). > > > > +If the subsystem has its own diagnostic macros then they should be used > > +instead of dev_dbg calls. > > +e.g. If you are using network subsystem, use netdev_dbg; > > +if you are using V4L, use v4l_dbg etc. > > +This standardises the output format in every subsystem. > > + > > +Depending on your changes, the following order of precedence > > +applies to printing messages: > > +1. [subsystem]_dbg() is preferred when you the > > The 'you' is unnecessary and incorrect. > > > +subsystem has its own diagnostic macros. > > +2. dev_dbg() is preferred when you have a generic struct device object. > > +3. pr_debug() is used when 1 and 2 above are not applicable. > > I think it's better to say "should be used". > > > +4. printk() should be avoided. > > + > > 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 > > messages should be compiled out when the DEBUG symbol is not defined (that > > I think we should also mention *_warn, *_err etc not just *_dbg. > > -- > Regards, > Levente Kurusa -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
Hi, 2014-03-04 12:48 GMT+01:00 yogesh : > This patch adds documentation that clarifies the use of various diagnostic > printing messages. It shows the preference of subsystem_dbg calls to dev_dbg > (whenever possible), as the first preferred format of logging debug messages. Please wrap your changelog at 80 characters a line. > Signed-off-by: Yogesh Chaudhari > --- > Documentation/CodingStyle | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle > index 7fe0546..9e0de25 100644 > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > @@ -662,6 +662,20 @@ 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 > particular device, defines pr_debug() and pr_info(). > > +If the subsystem has its own diagnostic macros then they should be used > +instead of dev_dbg calls. > +e.g. If you are using network subsystem, use netdev_dbg; > +if you are using V4L, use v4l_dbg etc. > +This standardises the output format in every subsystem. > + > +Depending on your changes, the following order of precedence > +applies to printing messages: > +1. [subsystem]_dbg() is preferred when you the The 'you' is unnecessary and incorrect. > +subsystem has its own diagnostic macros. > +2. dev_dbg() is preferred when you have a generic struct device object. > +3. pr_debug() is used when 1 and 2 above are not applicable. I think it's better to say "should be used". > +4. printk() should be avoided. > + > 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 > messages should be compiled out when the DEBUG symbol is not defined (that I think we should also mention *_warn, *_err etc not just *_dbg. -- Regards, Levente Kurusa -- 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/
[PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as the first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari --- Documentation/CodingStyle | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..9e0de25 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,20 @@ 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 particular device, defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when you the +subsystem has its own diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() is used when 1 and 2 above are not applicable. +4. printk() should be avoided. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- 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/
[PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as the first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com --- Documentation/CodingStyle | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..9e0de25 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,20 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when you the +subsystem has its own diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() is used when 1 and 2 above are not applicable. +4. printk() should be avoided. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
Hi, 2014-03-04 12:48 GMT+01:00 yogesh mr.yog...@gmail.com: This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as the first preferred format of logging debug messages. Please wrap your changelog at 80 characters a line. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com --- Documentation/CodingStyle | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..9e0de25 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,20 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when you the The 'you' is unnecessary and incorrect. +subsystem has its own diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() is used when 1 and 2 above are not applicable. I think it's better to say should be used. +4. printk() should be avoided. + 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 messages should be compiled out when the DEBUG symbol is not defined (that I think we should also mention *_warn, *_err etc not just *_dbg. -- Regards, Levente Kurusa -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as they first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com --- Documentation/CodingStyle | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..083f738 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,23 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when the subsystem has its own +diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() should be used when 1 and 2 above are not applicable. +4. printk() should be avoided. + +Note: The above order applies to diagnostic calls of all log levels viz: +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- Regards Yogesh On Tue, Mar 04, 2014 at 02:39:42PM +0100, Levente Kurusa wrote: Hi, 2014-03-04 12:48 GMT+01:00 yogesh mr.yog...@gmail.com: This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as the first preferred format of logging debug messages. Please wrap your changelog at 80 characters a line. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com --- Documentation/CodingStyle | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..9e0de25 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,20 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when you the The 'you' is unnecessary and incorrect. +subsystem has its own diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() is used when 1 and 2 above are not applicable. I think it's better to say should be used. +4. printk() should be avoided. + 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 messages should be compiled out when the DEBUG symbol is not defined (that I think we should also mention *_warn, *_err etc not just *_dbg. -- Regards, Levente Kurusa -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
Hi, [+CC Rob] 2014-03-04 15:31 GMT+01:00 yogesh mr.yog...@gmail.com: This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as they first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com Acked-by: Levente Kurusa le...@linux.com --- Documentation/CodingStyle | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..083f738 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,23 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when the subsystem has its own +diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() should be used when 1 and 2 above are not applicable. +4. printk() should be avoided. + +Note: The above order applies to diagnostic calls of all log levels viz: +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- Regards Yogesh [...] A lot better, but please next time send it as a separate mail with subject [PATCH v2] or something like that. Thanks! -- Regards, Levente Kurusa -- 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/
Re: [PATCH 1/1] Add documentation for proper usage and order of preference of calls to print diagnostic messages.
On 03/04/2014 06:31 AM, yogesh wrote: This patch adds documentation that clarifies the use of various diagnostic printing messages. It shows the preference of subsystem_dbg calls to dev_dbg (whenever possible), as they first preferred format of logging debug messages. Signed-off-by: Yogesh Chaudhari mr.yog...@gmail.com --- Documentation/CodingStyle | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..083f738 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -662,6 +662,23 @@ 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 particular device, linux/printk.h defines pr_debug() and pr_info(). +If the subsystem has its own diagnostic macros then they should be used +instead of dev_dbg calls. +e.g. If you are using network subsystem, use netdev_dbg; E.g., if you are +if you are using V4L, use v4l_dbg etc. +This standardises the output format in every subsystem. + +Depending on your changes, the following order of precedence +applies to printing messages: +1. [subsystem]_dbg() is preferred when the subsystem has its own +diagnostic macros. +2. dev_dbg() is preferred when you have a generic struct device object. +3. pr_debug() should be used when 1 and 2 above are not applicable. +4. printk() should be avoided. + +Note: The above order applies to diagnostic calls of all log levels viz: +*_emerg, *_alert, *_crit, *_err, *_warn, *_notice, *_info and *_dbg. + 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 messages should be compiled out when the DEBUG symbol is not defined (that -- -- ~Randy -- 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/
