Messages in this thread | | | Subject | Re: [PATCH] printk(): add KERN_CONT where needed | From | Joe Perches <> | Date | Mon, 09 Apr 2012 16:37:46 -0700 |
| |
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.
| |