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 23:57:10 +0000 [thread overview]
Message-ID: <1432339030.29657.20.camel@perches.com> (raw)
In-Reply-To: <05DE4AF3-20A6-40F6-BAC6-79C140E490AF@intel.com>
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 sjows that the mechanism it
goes through is called CDEBUG, a reasonable expectation should
be that it's a debugging message.
> CERROR is something that get's printed on the console, because it's believed
> to be serious error (At least that's how the theory for it's usage goes).
> It also gets rate-limited so that the console does not get overflown.
> (but the debug buffer gets the full version).
> (there's also LCONSOLE that always get's printed, but it does not get the
> prefixes like line numbers and stuff).
>
> CDEBUG on the other hand is a debugging message (of which ERROR messages are
> sort of a subset (D_ERROR mask)). You can fine-tune those to be noops or
> to go into console or to debug buffer only. Most of those are doing nothing
> because they are off in the default debug mask, until actually enabled.
>
> That CERROR usees CDEBUG underneath is just to share some common infrastructure.
>
> > I think it'd be clearer as
> > lustre_debug(ERROR, ...
> > even if the name and use style is a little longer.
>
> 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.
It'd be more intelligible if this CERROR became lustre_err
and the actual debugging uses were lustre_dbg
Perhaps it needs a better explanation somewhere not in the
code but in some external documentation. I haven't looked.
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 16:57:10 -0700 [thread overview]
Message-ID: <1432339030.29657.20.camel@perches.com> (raw)
In-Reply-To: <05DE4AF3-20A6-40F6-BAC6-79C140E490AF@intel.com>
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 sjows that the mechanism it
goes through is called CDEBUG, a reasonable expectation should
be that it's a debugging message.
> CERROR is something that get's printed on the console, because it's believed
> to be serious error (At least that's how the theory for it's usage goes).
> It also gets rate-limited so that the console does not get overflown.
> (but the debug buffer gets the full version).
> (there's also LCONSOLE that always get's printed, but it does not get the
> prefixes like line numbers and stuff).
>
> CDEBUG on the other hand is a debugging message (of which ERROR messages are
> sort of a subset (D_ERROR mask)). You can fine-tune those to be noops or
> to go into console or to debug buffer only. Most of those are doing nothing
> because they are off in the default debug mask, until actually enabled.
>
> That CERROR usees CDEBUG underneath is just to share some common infrastructure.
>
> > I think it'd be clearer as
> > lustre_debug(ERROR, ...
> > even if the name and use style is a little longer.
>
> 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.
It'd be more intelligible if this CERROR became lustre_err
and the actual debugging uses were lustre_dbg
Perhaps it needs a better explanation somewhere not in the
code but in some external documentation. I haven't looked.
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 16:57:10 -0700 [thread overview]
Message-ID: <1432339030.29657.20.camel@perches.com> (raw)
In-Reply-To: <05DE4AF3-20A6-40F6-BAC6-79C140E490AF@intel.com>
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 sjows that the mechanism it
goes through is called CDEBUG, a reasonable expectation should
be that it's a debugging message.
> CERROR is something that get's printed on the console, because it's believed
> to be serious error (At least that's how the theory for it's usage goes).
> It also gets rate-limited so that the console does not get overflown.
> (but the debug buffer gets the full version).
> (there's also LCONSOLE that always get's printed, but it does not get the
> prefixes like line numbers and stuff).
>
> CDEBUG on the other hand is a debugging message (of which ERROR messages are
> sort of a subset (D_ERROR mask)). You can fine-tune those to be noops or
> to go into console or to debug buffer only. Most of those are doing nothing
> because they are off in the default debug mask, until actually enabled.
>
> That CERROR usees CDEBUG underneath is just to share some common infrastructure.
>
> > I think it'd be clearer as
> > lustre_debug(ERROR, ...
> > even if the name and use style is a little longer.
>
> 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.
It'd be more intelligible if this CERROR became lustre_err
and the actual debugging uses were lustre_dbg
Perhaps it needs a better explanation somewhere not in the
code but in some external documentation. I haven't looked.
next prev parent reply other threads:[~2015-05-22 23:57 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 [this message]
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
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=1432339030.29657.20.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.