lkml.org 
[lkml]   [2012]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] printk(): add KERN_CONT where needed
From
Date
On Mon, 2012-04-09 at 16:08 -0700, Andrew Morton wrote:
> On Tue, 3 Apr 2012 05:00:10 +0200
> Kay Sievers <kay@vrfy.org> wrote:
>
> > > Maybe it'd be better to aggregate content rather like
> > > printk does. __Aggregate until you get a newline or a
> > > new KERN_<LEVEL>
> >
> > The continuation printk() can can always go wrong when multiple
> > threads do that in parallel. We can try to make it better with a
> > per-cpu buffer, but I guess there will always be a situation where
> > this can happen.
>
> Maybe we can be a bit smarter. For example, if `current' is unchanged
> and __builtin_return_address(0) is unchanged, keep on buffering.

There are dozens to hundreds of existing sequences
like:

void some_func(...)
{
printk("some additional data");
}

...

void some_device_init(...)
{
...
printk([KERN_LEVEL or not] "some initiator")
some_func();
printk("\n");
}

> It's all a bit hacky, but weeding out all those thousands of printks
> which never get printed anyway doesn't sound much fun either.

Nope. That isn't any fun.

So given the example above, maybe check if the
initial printk's __builtin_return_address(0) exists
in some level of the stack say up to 3 deep for each
subsequent printk.

I don't remember any threads spun off to emit printk
continuation lines so maybe that'd work reasonably
well.

> All a bit of a pain.

Too true.




\
 
 \ /
  Last update: 2012-04-10 01:39    [W:0.070 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site