linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).