All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>,
	Michael Shuey <shuey@purdue.edu>,
	"<devel@driverdev.osuosl.org>" <devel@driverdev.osuosl.org>,
	"<gregkh@linuxfoundation.org>" <gregkh@linuxfoundation.org>,
	"<kernel-janitors@vger.kernel.org>"
	<kernel-janitors@vger.kernel.org>,
	"<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
	"<HPDD-discuss@ml01.01.org>" <HPDD-discuss@ml01.01.org>,
	"<lustre-devel@lists.lustre.org>" <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
Date: Sat, 23 May 2015 00:18:05 +0000	[thread overview]
Message-ID: <1432340285.29657.26.camel@perches.com> (raw)
In-Reply-To: <863F0D66-99B1-4658-8A99-E3A843E0E8FC@intel.com>

On Sat, 2015-05-23 at 00:07 +0000, Drokin, Oleg wrote:
> On May 22, 2015, at 7:57 PM, Joe Perches wrote:
> > On Fri, 2015-05-22 at 21:16 +0000, Drokin, Oleg wrote:
> >> On May 22, 2015, at 11:42 AM, Joe Perches wrote:
> >>> On Fri, 2015-05-22 at 08:08 +0000, Drokin, Oleg wrote:
> >>>> On May 22, 2015, at 1:06 AM, Julia Lawall wrote:
> >>>>> On Thu, 21 May 2015, Michael Shuey wrote:
> >>>>> 
> >>>>>> That's a task (of many) I've been putting on the back burner until the code
> >>>>>> is cleaner.  It's also a HUGE change, since there are debug macros
> >>>>>> everywhere, and they all check a #define'd mask to see if they should fire,
> >>>>>> and the behavior is likely governed by parts of the lustre user land tools
> >>>>>> as well.
> >>>>>> 
> >>>>>> Suggestions are welcome.  Do other parts of the linux kernel define complex
> >>>>>> debugging macros like these, or is this a lustre-ism?  Any suggestions on
> >>>>>> how to handle this more in line with existing drivers?
> >>>>> 
> >>>>> Once you decide what to do, you can use Coccinelle to make the changes for
> >>>>> you.  So you shouldn't be put off by the number of code sites to change.
> >>>>> 
> >>>>> The normal functions are pr_err, pr_warn, etc.  Perhaps you can follow
> >>>>> Joe's suggestions if you really need something more complicated.
> >>>> 
> >>>> Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my perspective.
> >>> 
> >>> My issue with CERROR is the name is little misleading.
> >>> It's actually a debugging message.
> >>> #define CERROR(format, ...)  CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
> >> 
> >> Except it's not a debugging message.
> >> There is a clear distinction.
> > 
> > Not really.  If the first reading shows that the mechanism it
> > goes through is called CDEBUG, a reasonable expectation should
> > be that it's a debugging message.
> 
> Well, various pr_err/pr_dbg for example, go through printk in the end too.
> Do that make them the same?

No, because each is labeled with the KERN_<level> that it uses.

[]

> >> I wonder what is more clear about that in your opinion ve
> >> lustre_error/lustre_debug?
> > 
> > The fact that you have to explain this shows that it's
> > at least misleading unless you completely understand the
> > code.
> 
> Or you know, you might take the function name at the face value
> and assume that CERROR means it's an error and CDEBUG means it's a debug message?

Maybe, but I think that it'd be better if the mechanism
it uses was more plainly named something like lustre_log.




WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
Date: Fri, 22 May 2015 17:18:05 -0700	[thread overview]
Message-ID: <1432340285.29657.26.camel@perches.com> (raw)
In-Reply-To: <863F0D66-99B1-4658-8A99-E3A843E0E8FC@intel.com>

On Sat, 2015-05-23 at 00:07 +0000, Drokin, Oleg wrote:
> On May 22, 2015, at 7:57 PM, Joe Perches wrote:
> > On Fri, 2015-05-22 at 21:16 +0000, Drokin, Oleg wrote:
> >> On May 22, 2015, at 11:42 AM, Joe Perches wrote:
> >>> On Fri, 2015-05-22 at 08:08 +0000, Drokin, Oleg wrote:
> >>>> On May 22, 2015, at 1:06 AM, Julia Lawall wrote:
> >>>>> On Thu, 21 May 2015, Michael Shuey wrote:
> >>>>> 
> >>>>>> That's a task (of many) I've been putting on the back burner until the code
> >>>>>> is cleaner.  It's also a HUGE change, since there are debug macros
> >>>>>> everywhere, and they all check a #define'd mask to see if they should fire,
> >>>>>> and the behavior is likely governed by parts of the lustre user land tools
> >>>>>> as well.
> >>>>>> 
> >>>>>> Suggestions are welcome.  Do other parts of the linux kernel define complex
> >>>>>> debugging macros like these, or is this a lustre-ism?  Any suggestions on
> >>>>>> how to handle this more in line with existing drivers?
> >>>>> 
> >>>>> Once you decide what to do, you can use Coccinelle to make the changes for
> >>>>> you.  So you shouldn't be put off by the number of code sites to change.
> >>>>> 
> >>>>> The normal functions are pr_err, pr_warn, etc.  Perhaps you can follow
> >>>>> Joe's suggestions if you really need something more complicated.
> >>>> 
> >>>> Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my perspective.
> >>> 
> >>> My issue with CERROR is the name is little misleading.
> >>> It's actually a debugging message.
> >>> #define CERROR(format, ...)  CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
> >> 
> >> Except it's not a debugging message.
> >> There is a clear distinction.
> > 
> > Not really.  If the first reading shows that the mechanism it
> > goes through is called CDEBUG, a reasonable expectation should
> > be that it's a debugging message.
> 
> Well, various pr_err/pr_dbg for example, go through printk in the end too.
> Do that make them the same?

No, because each is labeled with the KERN_<level> that it uses.

[]

> >> I wonder what is more clear about that in your opinion ve
> >> lustre_error/lustre_debug?
> > 
> > The fact that you have to explain this shows that it's
> > at least misleading unless you completely understand the
> > code.
> 
> Or you know, you might take the function name at the face value
> and assume that CERROR means it's an error and CDEBUG means it's a debug message?

Maybe, but I think that it'd be better if the mechanism
it uses was more plainly named something like lustre_log.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>,
	Michael Shuey <shuey@purdue.edu>,
	"<devel@driverdev.osuosl.org>" <devel@driverdev.osuosl.org>,
	"<gregkh@linuxfoundation.org>" <gregkh@linuxfoundation.org>,
	"<kernel-janitors@vger.kernel.org>"
	<kernel-janitors@vger.kernel.org>,
	"<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
	"<HPDD-discuss@ml01.01.org>" <HPDD-discuss@ml01.01.org>,
	"<lustre-devel@lists.lustre.org>" <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
Date: Fri, 22 May 2015 17:18:05 -0700	[thread overview]
Message-ID: <1432340285.29657.26.camel@perches.com> (raw)
In-Reply-To: <863F0D66-99B1-4658-8A99-E3A843E0E8FC@intel.com>

On Sat, 2015-05-23 at 00:07 +0000, Drokin, Oleg wrote:
> On May 22, 2015, at 7:57 PM, Joe Perches wrote:
> > On Fri, 2015-05-22 at 21:16 +0000, Drokin, Oleg wrote:
> >> On May 22, 2015, at 11:42 AM, Joe Perches wrote:
> >>> On Fri, 2015-05-22 at 08:08 +0000, Drokin, Oleg wrote:
> >>>> On May 22, 2015, at 1:06 AM, Julia Lawall wrote:
> >>>>> On Thu, 21 May 2015, Michael Shuey wrote:
> >>>>> 
> >>>>>> That's a task (of many) I've been putting on the back burner until the code
> >>>>>> is cleaner.  It's also a HUGE change, since there are debug macros
> >>>>>> everywhere, and they all check a #define'd mask to see if they should fire,
> >>>>>> and the behavior is likely governed by parts of the lustre user land tools
> >>>>>> as well.
> >>>>>> 
> >>>>>> Suggestions are welcome.  Do other parts of the linux kernel define complex
> >>>>>> debugging macros like these, or is this a lustre-ism?  Any suggestions on
> >>>>>> how to handle this more in line with existing drivers?
> >>>>> 
> >>>>> Once you decide what to do, you can use Coccinelle to make the changes for
> >>>>> you.  So you shouldn't be put off by the number of code sites to change.
> >>>>> 
> >>>>> The normal functions are pr_err, pr_warn, etc.  Perhaps you can follow
> >>>>> Joe's suggestions if you really need something more complicated.
> >>>> 
> >>>> Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my perspective.
> >>> 
> >>> My issue with CERROR is the name is little misleading.
> >>> It's actually a debugging message.
> >>> #define CERROR(format, ...)  CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
> >> 
> >> Except it's not a debugging message.
> >> There is a clear distinction.
> > 
> > Not really.  If the first reading shows that the mechanism it
> > goes through is called CDEBUG, a reasonable expectation should
> > be that it's a debugging message.
> 
> Well, various pr_err/pr_dbg for example, go through printk in the end too.
> Do that make them the same?

No, because each is labeled with the KERN_<level> that it uses.

[]

> >> I wonder what is more clear about that in your opinion ve
> >> lustre_error/lustre_debug?
> > 
> > The fact that you have to explain this shows that it's
> > at least misleading unless you completely understand the
> > code.
> 
> Or you know, you might take the function name at the face value
> and assume that CERROR means it's an error and CDEBUG means it's a debug message?

Maybe, but I think that it'd be better if the mechanism
it uses was more plainly named something like lustre_log.




  reply	other threads:[~2015-05-23  0:18 UTC|newest]

Thread overview: 125+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-21 19:50 [PATCH v4 00/13] staging: lustre: lnet: code cleanups Mike Shuey
2015-05-21 19:50 ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 01/13] staging: lustre: lnet: lnet: code cleanups - variable declarations Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 02/13] staging: lustre: lnet: dead code - remove lnet_fini_locks Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 03/13] staging: lustre: lnet: dead code - remove LNetSetAsync Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 04/13] staging: lustre: lnet: lnet: Module is LNet, not Portals Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 05/13] staging: lustre: lnet: o2iblnd: code cleanup - align whitespace Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-22 13:03   ` Dan Carpenter
2015-05-22 13:03     ` Dan Carpenter
2015-05-21 19:50 ` [PATCH v4 06/13] staging: lustre: lnet: socklnd: code cleanup - align spacing Mike Shuey
2015-05-21 19:50 ` [PATCH v4 07/13] staging: lustre: lnet: selftest: code cleanup - variable spacing, indentation Mike Shuey
2015-05-21 19:50 ` [PATCH v4 08/13] staging: lustre: lnet: remove LNET_MUTEX_LOCK macro Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 09/13] staging: lustre: lnet: lnet: remove dead code, fix checkpatch.pl issue Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 21:00   ` Joe Perches
2015-05-21 21:00     ` Joe Perches
2015-05-21 21:29     ` Julia Lawall
2015-05-21 21:29       ` Julia Lawall
2015-05-21 22:04       ` [lustre-devel] " Michael Shuey
2015-05-22  2:46         ` Joe Perches
2015-05-22  2:46           ` Joe Perches
2015-05-22  2:46           ` [lustre-devel] " Joe Perches
2015-05-22  5:06         ` Julia Lawall
2015-05-22  5:06           ` Julia Lawall
2015-05-22  5:06           ` [lustre-devel] " Julia Lawall
2015-05-22  8:08           ` Drokin, Oleg
2015-05-22  8:08             ` [lustre-devel] " Drokin, Oleg
2015-05-22 15:42             ` Joe Perches
2015-05-22 15:42               ` Joe Perches
2015-05-22 15:42               ` [lustre-devel] " Joe Perches
2015-05-22 21:16               ` Drokin, Oleg
2015-05-22 21:16                 ` [lustre-devel] " Drokin, Oleg
2015-05-22 23:57                 ` Joe Perches
2015-05-22 23:57                   ` Joe Perches
2015-05-22 23:57                   ` [lustre-devel] " Joe Perches
2015-05-23  0:07                   ` Drokin, Oleg
2015-05-23  0:07                     ` [lustre-devel] " Drokin, Oleg
2015-05-23  0:18                     ` Joe Perches [this message]
2015-05-23  0:18                       ` Joe Perches
2015-05-23  0:18                       ` [lustre-devel] " Joe Perches
2015-05-23  0:25                       ` Drokin, Oleg
2015-05-23  0:25                         ` [lustre-devel] " Drokin, Oleg
2015-05-23  0:36                         ` Joe Perches
2015-05-23  0:36                           ` Joe Perches
2015-05-23  0:36                           ` [lustre-devel] " Joe Perches
2015-05-23  3:13                           ` [HPDD-discuss] " Patrick Farrell
2015-05-23  3:13                             ` [lustre-devel] " Patrick Farrell
     [not found]     ` <CABqvwjs=S1VrCHe7M4JnDikGBVN3yqjNMrtSA=UvftGmxSasRQ@mail.gmail.com>
2015-05-22  3:06       ` Joe Perches
2015-05-22  3:06         ` Joe Perches
2015-05-22  8:04       ` Drokin, Oleg
2015-05-22 10:00         ` Julia Lawall
2015-05-22 10:00           ` Julia Lawall
2015-05-23  6:28     ` [PATCH] checkpatch: Categorize some long line length checks Joe Perches
2015-05-23  6:28       ` Joe Perches
2015-05-23 11:32       ` Julia Lawall
2015-05-23 11:32         ` Julia Lawall
2015-05-23 17:26         ` Joe Perches
2015-05-23 17:26           ` Joe Perches
2015-05-23 18:07           ` Dan Carpenter
2015-05-23 18:07             ` Dan Carpenter
2015-05-23 18:13             ` Joe Perches
2015-05-23 18:13               ` Joe Perches
2015-05-23 18:21               ` Dan Carpenter
2015-05-23 18:21                 ` Dan Carpenter
2015-05-24  2:49           ` [PATCH V2] " Joe Perches
2015-05-21 19:50 ` [PATCH v4 11/13] staging: lnet: o2iblnd: checkpatch.pl fixes Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-22 10:49   ` Dan Carpenter
2015-05-22 10:49     ` Dan Carpenter
2015-05-21 19:50 ` [PATCH v4 12/13] staging: lustre: lnet: socklnd: checkpatch.pl cleanups Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH v4 13/13] staging: lustre: lnet: selftest: checkpatch.pl fixes Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 01/13] staging: lustre: lnet: lnet: code cleanups - variable declarations Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 02/13] staging: lustre: lnet: dead code - remove lnet_fini_locks Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 03/13] staging: lustre: lnet: dead code - remove LNetSetAsync Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 04/13] staging: lustre: lnet: lnet: Module is LNet, not Portals Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 05/13] staging: lustre: lnet: o2iblnd: code cleanup - align whitespace Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 06/13] staging: lustre: lnet: socklnd: code cleanup - align spacing Mike Shuey
2015-05-21 19:50 ` [PATCH 07/13] staging: lustre: lnet: selftest: code cleanup - variable spacing, indentation Mike Shuey
2015-05-21 19:50 ` [PATCH 08/13] staging: lustre: lnet: remove LNET_MUTEX_LOCK macro Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 09/13] staging: lustre: lnet: lnet: remove dead code, fix checkpatch.pl issue Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 11/13] staging: lnet: o2iblnd: " Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 12/13] staging: lustre: lnet: socklnd: checkpatch.pl cleanups Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-21 19:50 ` [PATCH 13/13] staging: lustre: lnet: selftest: checkpatch.pl fixes Mike Shuey
2015-05-21 19:50   ` Mike Shuey
2015-05-22 10:55   ` Dan Carpenter
2015-05-22 10:55     ` Dan Carpenter
2015-05-22  9:21 ` [PATCH v4 00/13] staging: lustre: lnet: code cleanups Dan Carpenter
2015-05-22  9:21   ` Dan Carpenter
2015-05-22 22:48   ` [lustre-devel] " Michael Shuey
2015-05-23 10:14     ` Dan Carpenter
2015-05-23 10:14       ` Dan Carpenter
2015-05-23 10:14       ` [lustre-devel] " Dan Carpenter
2015-05-23 12:09       ` Michael Shuey
2015-05-23 12:09         ` Michael Shuey
2015-05-23 12:09         ` [lustre-devel] " Michael Shuey
2015-05-23 12:39         ` Sudip Mukherjee
2015-05-23 12:51           ` Sudip Mukherjee
2015-05-23 12:39           ` Sudip Mukherjee
2015-05-23 14:05           ` Michael Shuey
2015-05-23 14:05             ` Michael Shuey
2015-05-23 14:05             ` [lustre-devel] " Michael Shuey
2015-05-31  2:24             ` Greg KH
2015-05-31  2:24               ` Greg KH
2015-05-31  2:24               ` [lustre-devel] " Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1432340285.29657.26.camel@perches.com \
    --to=joe@perches.com \
    --cc=HPDD-discuss@ml01.01.org \
    --cc=Julia.Lawall@lip6.fr \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=oleg.drokin@intel.com \
    --cc=shuey@purdue.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.