From: Nishanth Menon <nm@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Nishanth Menon <menon.nishanth@gmail.com>,
"Gopinath, Thara" <thara@ti.com>,
linux-omap <linux-omap@vger.kernel.org>,
Kevin Hilman <khilman@deeprootsystems.com>
Subject: Re: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
Date: Fri, 6 Aug 2010 08:10:44 -0500 [thread overview]
Message-ID: <4C5C09D4.50406@ti.com> (raw)
In-Reply-To: <20100806121807.GD31326@sirena.org.uk>
Mark Brown had written, on 08/06/2010 07:18 AM, the following:
> On Fri, Aug 06, 2010 at 06:08:03AM -0500, Nishanth Menon wrote:
>
>> Well that is my motivation here. if driver reports a warning to kernel
>> syslog, well, I expect the log to contain the function name for me to
>> maintain faster.
>
> That's really not the expectation for Linux log messages - the general
> approach to find the source of a message is generally to just grep for
> the message text which is usually very effective.
taking a small sample set of pr_xyz(); (pr which spans a single line):
$ git grep pr_ drivers/|grep ")"|grep __func__|wc -l
589
$ git grep pr_ drivers/|grep ")"|grep -v __func__|wc -l
5373
$ git grep pr_fmt drivers/|wc -l
138
Reading Documentation/dynamic-debug-howto.txt, I see that you are in a
one way right. I can get fine grained control over the log by enabling
CONFIG_DYNAMIC_DEBUG.
At the same time, I have wondered on the usage of pr_fmt() in many of
the drivers. in a way, if i wanted to be that verbose in a driver, I
could in theory do:
#define pr_fmt(fmt) "%s:" fmt, __func__ and get the benefit throughout
the file..
but overall, I still disagree that we dont need to have the function
name in log is a speed booster for maintenance folks.
a) when the strings are split up when they go multiple lines:
E.g.:
"abcd "
"efg"
print comes out abcd efg
i) you do a git grep "abcd efg" will return nada
ii) if you do a git grep of "abcd", you will probably see half a dozen
prints there, then open each file to see where the "real" message is,
and you find the file searching a bit
b) when there are couple more usage in cases of commonly used error
message- (e.g. invalid parameters), you end up getting multiple hits,
and you are left guessing where it came from
in this example: lets see: (on l-o pm branch):
git grep "DEBUG option not enabled" .
arch/arm/mach-omap2/smartreflex.c: pr_notice("DEBUG option
not enabled!\n \
arch/arm/mach-omap2/voltage.c: pr_notice("DEBUG option not
enabled!\n \
now open up both the files to find exactly what you are looking for.
c) time required:
$ time git grep "DEBUG option not enabled" .
arch/arm/mach-omap2/smartreflex.c: pr_notice("DEBUG option
not enabled!\n \
arch/arm/mach-omap2/voltage.c: pr_notice("DEBUG option not
enabled!\n \
real 1m34.722s
user 0m0.440s
sys 0m1.820s
Vs cscope or ctags where it is rather instantaneous if you know the
function name..
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-08-06 13:10 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-05 22:24 [PM-SR][PATCH 00/12 v2] omap3: sr: janitor series Nishanth Menon
2010-08-05 22:24 ` [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx Nishanth Menon
2010-08-06 7:42 ` Gopinath, Thara
2010-08-06 11:08 ` Nishanth Menon
2010-08-06 12:18 ` Mark Brown
2010-08-06 13:10 ` Nishanth Menon [this message]
2010-08-06 13:32 ` Mark Brown
2010-08-06 13:37 ` Nishanth Menon
2010-08-06 13:50 ` Mark Brown
2010-08-13 10:39 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 02/12] omap3: voltage: make required variables static Nishanth Menon
2010-08-06 7:39 ` Gopinath, Thara
2010-08-06 11:02 ` Nishanth Menon
2010-08-05 22:24 ` [PM-SR][PATCH 03/12] omap3: voltage: expose omap_change_voltscale_method Nishanth Menon
2010-08-06 7:07 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx Nishanth Menon
2010-08-06 7:11 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr Nishanth Menon
2010-08-06 7:27 ` Gopinath, Thara
2010-08-06 11:00 ` Nishanth Menon
2010-08-05 22:24 ` [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error Nishanth Menon
2010-08-06 7:24 ` Gopinath, Thara
2010-08-06 10:59 ` Nishanth Menon
2010-08-13 10:31 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static Nishanth Menon
2010-08-06 7:24 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx Nishanth Menon
2010-08-06 4:38 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required Nishanth Menon
2010-08-06 4:51 ` Gopinath, Thara
2010-08-06 10:54 ` Nishanth Menon
2010-08-05 22:24 ` [PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir Nishanth Menon
2010-08-06 4:56 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static Nishanth Menon
2010-08-06 4:57 ` Gopinath, Thara
2010-08-05 22:24 ` [PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static Nishanth Menon
2010-08-06 7:32 ` Gopinath, Thara
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=4C5C09D4.50406@ti.com \
--to=nm@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=menon.nishanth@gmail.com \
--cc=thara@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).