mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: Rob Landley <rob@landley.net>
Cc: Indan Zupancic <indan@nul.nu>,
	linux-tiny@selenic.com,
	Michael Opdenacker <michael@free-electrons.com>,
	CE Linux Developers List <celinux-dev@tree.celinuxforum.org>,
	linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Announce] Linux-tiny project revival
Date: Fri, 21 Sep 2007 17:34:05 -0400	[thread overview]
Message-ID: <4477DB43-766B-4057-B33D-357A73AF69B0@mac.com> (raw)
In-Reply-To: <200709201818.42125.rob@landley.net>

On Sep 20, 2007, at 19:18:41, Rob Landley wrote:
> On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
>> But the problem remains that there are printk's which don't have a  
>> KERN_* as the first argument. Those are also impossible to get rid  
>> off in this way, as the loglevel is unknown (and you don't want  
>> partially printed messages).
>>
>> So adding the comma is really needed and in addition all printk's  
>> without a loglevel should get one. Which clutters the code and may  
>> increase codesize.
>
> It's ok to _explicitly_ not have a loglevel, and thus take a known  
> default.  The problem is printing out less than a full line,  
> continuing it later, and not making obvious at compile time what  
> the level of this chunk is.

That's actually a fairly straightforward problem to solve.  Really we  
ought to be able to guarantee that lines from different CPUs are not  
intermixed.  This can end up in a log like this:

info: Current device state: <1>netdev watchdog timeout: eth0
reg1=0xABCD reg2=0xDEADBEEF

Clearly unpleasant, no?  Really any logging which wants to print out  
a bunch of stuff with multiple printk()s should use an API something  
like this:

Option 1: Buffer allocated with kmalloc().  Sleep-ish context, can  
handle failures easily
> struct printk_queue qpk;
> if (qprintk_kmalloc(&qpk, level, GFP_KERNEL))
> 	return -ENOMEM;
>
> qprintk(&qpk, "Some string here:");
> qprintk(&qpk, " %d, %s, %d", 4, some_string, 42);
> qprintk_finish(&qpk);


Option 2: Preallocated per-cpu buffer.  preempt_disable()d
> struct printk_queue qpk;
> qprintk_percpu(&qpk, level);
> [...]
> qprintk_finish(&qpk);


Option 3: Preallocated per-cpu interrupts-only buffer.  Only from  
code which may interrupt a preempt_disable() section
> struct printk_queue qpk;
> qprintk_irq(&pqk, level)
> [...]
> qprintk_finish(&qpk);


For all of the above, the final "qprintk_finish()" call would  
essentially take the printk spinlock and write the contents of the  
qpk->buffer into the dmesg ringbuffer, inserting ("<%d>", level) at  
the beginning and after each newline.  The buffers would all be some  
useful fixed size (a page?); if you need more than that then you are  
probably trying to queue too much and excess data would be truncated.

Since the level would be a constant passed to qprintk_ 
{kmalloc,percpu,irq} in almost every case, you could easily do  
something like this:

static inline int qprintk_kmalloc(struct printk_queue *qpk,
		unsigned int level, gfp_t gfp)
{
	if (level > CONFIG_MAX_LOG_LEVEL) {
		qpk->type = QPRINTK_TYPE_NONE; /* also 0 */
		qpk->buffer = NULL;
		return 0;
	}

	_qprintk_kmalloc(qpk, level, gfp);
}

#define qprintk(QPK, FMT...) do { \
		if ((QPK)->type)
			_qprintk(QPK, FMT);
	} while(0)


With a bit more glue that would cause GCC to notice that for a given  
qprintk_kmalloc the "qpk->type" is always zero because the level is  
too high, and therefore it would optimize out *ALL* of the  
_qprintk_kmalloc(), _qprintk(), and _qprintk_finish() calls.

Cheers,
Kyle Moffett


  parent reply	other threads:[~2007-09-21 21:34 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-19 18:03 Tim Bird
2007-09-19 18:47 ` Luis R. Rodriguez
2007-09-19 19:31   ` Tim Bird
2007-09-19 19:01 ` Christian MICHON
2007-09-19 19:28 ` Andi Kleen
2007-09-19 19:41   ` Tim Bird
2007-09-19 20:45     ` Valdis.Kletnieks
2007-09-19 21:29       ` Tim Bird
2007-09-19 22:29         ` Michael Opdenacker
2007-09-19 21:28 ` [Celinux-dev] " Andrew Morton
2007-09-19 21:41   ` Tim Bird
2007-09-19 22:38     ` Michael Opdenacker
2007-09-20  9:10       ` Andy Whitcroft
2007-09-20 17:10         ` Monster switch for small size (was Linux-tiny revival) Tim Bird
2007-09-20 21:41           ` Rob Landley
2007-09-20 20:50             ` Randy Dunlap
2007-09-21  6:35             ` Christian MICHON
2007-09-20 23:02   ` [Celinux-dev] [Announce] Linux-tiny project revival Rob Landley
2007-09-20 20:38 ` Rob Landley
2007-09-20 19:58   ` Alexey Dobriyan
2007-09-20 20:22     ` printk proposal - (was Linux-tiny project revival) Tim Bird
2007-09-21 19:07       ` Alexey Dobriyan
2007-09-21 20:53         ` Rob Landley
2007-09-20 22:02     ` [Announce] Linux-tiny project revival Rob Landley
2007-09-20 21:22       ` Jared Hulbert
2007-09-20 22:53         ` Rob Landley
2007-09-20 22:15       ` [Celinux-dev] " Gross, Mark
2007-09-21  0:57         ` Message codes (Re: [Announce] Linux-tiny project revival) Oleg Verych
2007-09-21 14:18           ` Gross, Mark
2007-09-21 21:15             ` Rob Landley
2007-09-21 22:12               ` Gross, Mark
2007-09-21 22:33                 ` Joe Perches
2007-09-21 22:39                   ` Gross, Mark
2007-09-22  1:55               ` Oleg Verych
2007-09-21 13:29       ` [Announce] Linux-tiny project revival Dick Streefland
2007-09-20 20:16   ` Joe Perches
2007-09-25 11:43     ` [Celinux-dev] " Geert Uytterhoeven
2007-09-20 21:26   ` Indan Zupancic
2007-09-20 23:18     ` Rob Landley
2007-09-20 23:06       ` Indan Zupancic
2007-09-21  6:29         ` Sam Ravnborg
2007-09-24 18:13           ` Adrian Bunk
2007-09-26  6:24             ` Rob Landley
2007-09-21 17:16       ` Valdis.Kletnieks
2007-09-21 17:45         ` Joe Perches
2007-09-21 23:05           ` Rob Landley
2007-09-21 23:08             ` Joe Perches
2007-09-21 21:34       ` Kyle Moffett [this message]
2007-09-21 22:05         ` Joe Perches
2007-09-21 22:57           ` Kyle Moffett
2007-09-20 21:58   ` Tim Bird
2007-09-20 22:14     ` Joe Perches
2007-09-21  0:28       ` Rob Landley
2007-09-21  0:03         ` Joe Perches
2007-09-20 23:11     ` Rob Landley
2007-09-21 12:27   ` Bill Davidsen
2007-09-27  7:00   ` Arnd Bergmann
2007-09-27 16:35     ` Indan Zupancic
2007-09-27 22:21       ` Arnd Bergmann
2007-09-28  8:39         ` Bernd Petrovitsch
2007-09-30 20:37           ` Jörn Engel
2007-09-28  0:06     ` Rob Landley
2007-09-28 14:36       ` Dick Streefland

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=4477DB43-766B-4057-B33D-357A73AF69B0@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=celinux-dev@tree.celinuxforum.org \
    --cc=indan@nul.nu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tiny@selenic.com \
    --cc=michael@free-electrons.com \
    --cc=rob@landley.net \
    /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

all inboxes | Powered by JetHome®