From: Zach Brown <zach.brown@oracle.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] check pr_debug() arguments
Date: Mon, 11 Sep 2006 11:36:44 -0700 [thread overview]
Message-ID: <4505ACBC.9050505@oracle.com> (raw)
In-Reply-To: <20060908164908.abb98076.akpm@osdl.org>
>> This results in a seemingly insignificant code size increase. A x86-64
>> allyesconfig:
>>
>> text data bss dec hex filename
>> 25354768 7191098 4854720 37400586 23ab00a vmlinux.before
>> 25354945 7191138 4854720 37400803 23ab0e3 vmlinux
>
> Which would indicate that we might have expressions-with-side-effects
> inside pr_debug() statements somewhere, which is risky. I wonder where?
I browsed through some of the functions that bloat-o-meter reported an
increase for. Some seemed reasonable as they used things like current
or AFFS_I() in arguments. Others seemed pretty mysterious as they
didn't have obvious pr_debug() calls.
$ uname -m ; gcc --version
x86_64
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
> btw, what's up with aio.c using a combination of pr_debug() and dprintk(),
> and a combination of `#ifdef DEBUG' and `#if DEBUG > 1'? Confusing.
I'm not sure how it got that way but I don't think anyone will object to
simplifying it. I'll spend those 5 minutes :).
> It would be nice to have a single way of doing developer-debug in-tree. We
> have 182(!) different definitions of dprintk(). Please nobody cc me on that
> discussion though ;)
Agreed, on both counts :).
- z
prev parent reply other threads:[~2006-09-11 18:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-08 22:54 [PATCH 0/10] introduction: check pr_debug() arguments Zach Brown
2006-09-08 22:54 ` [PATCH 1/10] futex: remove extra pr_debug format specifications Zach Brown
2006-09-08 22:54 ` [PATCH 2/10] aio: use size_t length modifier in pr_debug format arguments Zach Brown
2006-09-08 22:54 ` [PATCH 3/10] configfs: use size_t length modifier in pr_debug format argument Zach Brown
2006-09-09 0:15 ` Joel Becker
2006-09-08 22:54 ` [PATCH 4/10] sysfs: use size_t length modifier in pr_debug format arguments Zach Brown
2006-09-08 22:55 ` [PATCH 5/10] umem: repair nonexistant bh pr_debug reference Zach Brown
2006-09-08 22:55 ` [PATCH 6/10] tipar: repair nonexistant pr_debug argument use Zach Brown
2006-09-08 22:55 ` [PATCH 7/10] dell_rbu: fix pr_debug argument warnings Zach Brown
2006-09-08 22:55 ` [PATCH 8/10] ifb: replace missing comma to separate pr_debug arguments Zach Brown
2006-09-08 22:55 ` [PATCH 9/10] trident: use size_t length modifier in pr_debug format arguments Zach Brown
2006-09-08 22:55 ` [PATCH 10/10] check pr_debug() arguments Zach Brown
2006-09-08 23:49 ` Andrew Morton
2006-09-11 18:36 ` Zach Brown [this message]
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=4505ACBC.9050505@oracle.com \
--to=zach.brown@oracle.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/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.