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
next prev 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®