From: Marc Andre Tanner <mat@brain-dump.org>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Tim Bird <tim.bird@am.sony.com>,
linux-embedded@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/7] printk: provide a filtering macro for printk
Date: Fri, 4 Sep 2009 16:05:16 +0200 [thread overview]
Message-ID: <20090904140516.GA6524@debbook.brain-dump.org> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190901C55DE5@mi8nycmail19.Mi8.com>
On Wed, Sep 02, 2009 at 02:22:52PM -0400, H Hartley Sweeten wrote:
> On Wednesday, September 02, 2009 10:05 AM, Tim Bird wrote:
> > Marc Andre Tanner wrote:
> >> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
> >>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
> >>>> Some places in the kernel break the message into pieces, like so:
> >>>>
> >>>> printk(KERN_ERR, "Error: first part ");
> >>>> ...
> >>>> printk(" more info for error.\n");
> >>> Technically, shouldn't the second part of the message actually be:
> >>>
> >>> printk(KERN_CONT " more info for error.\n");
> >>>
> >>> Maybe some mechanism could be created to handle the continued message
> >>> if they have the KERN_CONT?
> >>
> >> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
> >> to change that.
> >>
> >>>> These parts would not be handled consistently under certain
> >>>> conditions.
> >>>>
> >>>> It would be confusing to see only part of the message,
> >>>> but I don't know how often this construct is used.
> >>
> >> $ grep -R KERN_CONT linux-2.6 | wc -l
> >> 373
> >>
> >>>> Maybe
> >>>> another mechanism is needed to ensure that continuation
> >>>> printk lines have the same log level as their start strings.
> >>
> >> I currently don't see a way to achieve this with the CPP.
> >
> > If it's that few, then maybe it's OK to actually change
> > the code for those printk statements. (Heck, these locations
> > were all changed in the last 2 years anyway.)
> >
> > I'm just brainstorming here, but how about changing them from:
> > printk(KERN_INFO "foo");
> > printk(KERN_CONT "bar\n");
> > to:
> > printk(KERN_INFO "foo");
> > printk_cont(KERN_INFO "bar\n");
>
> Unfortunately not all the continued printk statements in the kernel are
> properly tagged with KERN_CONT (or pr_cont, etc.).
Yes and a quick search revealed that there are actually quite a lot of
those untagged messages.
As I needed some distraction from some other work I played around a bit
more with a solution which wouldn't require to change existing kernel
code. It uses a variable which would have to be available in every
function to store the loglevel of messages which are split over multiple
printk calls. Here is what I came up with so far:
#define PRINTK_IS_LINE(fmt) ( \
((const char*)(fmt))[sizeof((fmt)) - 2] == '\n' \
)
#define PRINTK_LEVEL(fmt) ( \
(((const char *)(fmt))[0] == '<' && \
((const char *)(fmt))[1] >= '0' && \
((const char *)(fmt))[1] <= '9' \
) ? ((const char *)(fmt))[1] - '0' : 4 \
)
#define printk(fmt, ...) ({ \
int __printk_ret = 0; \
int __printk_level = __printk_cont_level; \
\
if (__builtin_constant_p((fmt)) && ((fmt))) { \
/* check if we are dealing with a line ending */ \
if (PRINTK_IS_LINE((fmt))) { \
/* check if it was a whole line */ \
if (__printk_cont_level == -1) \
__printk_level = PRINTK_LEVEL((fmt)); \
__printk_cont_level = -1; \
} else if (__printk_cont_level == -1) /* first part of a line? */ \
__printk_level = __printk_cont_level = PRINTK_LEVEL((fmt)); \
} \
\
if (!__builtin_constant_p((fmt)) || __printk_level <= CONFIG_PRINTK_VERBOSITY) \
__printk_ret = printk((fmt), ##__VA_ARGS__); \
\
__printk_ret; \
})
Apart from the fact that it's getting uglier it obviously depends on
the availability of __printk_cont_level (which would get compiled out,
at least I hope so) in every function.
So
void demo() {
...
}
would have to become:
void demo() {
int __printk_cont_level = -1;
...
}
I don't know whether this is possible at all through some kind of gcc
magic. There is also the problem of introducing warnings when
__prink_cont_level isn't used in a function but I guess this could be
dealt with some __attribute__ setting.
Anyway just wanted to share the results of a brainstorming session.
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
next prev parent reply other threads:[~2009-09-04 14:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 22:31 [RFC|PATCH] Compile time printk verbosity Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 1/7] printk: introduce CONFIG_PRINTK_VERBOSITY Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 2/7] printk: move printk to the end of the file Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 3/7] printk: introduce printk_unfiltered as an alias to printk Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 4/7] drivers: replace printk with printk_unfiltered Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 5/7] drivers: make macro independent of printk's return value Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 6/7] video/stk-webcam: change use of STK_ERROR Marc Andre Tanner
2009-09-01 22:31 ` [PATCH 7/7] printk: provide a filtering macro for printk Marc Andre Tanner
2009-09-01 23:24 ` Tim Bird
2009-09-01 23:32 ` H Hartley Sweeten
2009-09-02 13:09 ` Marc Andre Tanner
2009-09-02 17:05 ` Tim Bird
2009-09-02 17:31 ` Tim Bird
2009-09-02 18:22 ` H Hartley Sweeten
2009-09-04 14:05 ` Marc Andre Tanner [this message]
2009-09-10 9:22 ` Geert Uytterhoeven
2009-09-01 23:35 ` Jamie Lokier
2009-09-02 9:03 ` Marc Andre Tanner
2009-09-02 9:54 ` Marc Andre Tanner
2009-09-02 11:06 ` Jamie Lokier
2009-09-02 12:25 ` Bill Gatliff
2009-09-02 12:44 ` Marc Andre Tanner
2009-09-02 12:54 ` Mike Frysinger
2009-09-02 14:07 ` Marc Andre Tanner
2009-09-02 14:30 ` Jamie Lokier
2009-09-01 23:37 ` [RFC|PATCH] Compile time printk verbosity Mike Frysinger
2009-09-02 8:57 ` Marc Andre Tanner
2009-09-02 9:11 ` Mike Frysinger
2009-09-02 9:47 ` Marc Andre Tanner
2009-09-02 9:56 ` Mike Frysinger
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=20090904140516.GA6524@debbook.brain-dump.org \
--to=mat@brain-dump.org \
--cc=hartleys@visionengravers.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tim.bird@am.sony.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).