lkml.org 
[lkml]   [2012]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: pr_cat() + CATSTR(name, size)?
From
Date
On Wed, 2012-07-11 at 17:14 +0200, Kay Sievers wrote:
> On Wed, Jul 11, 2012 at 5:01 PM, Joe Perches <joe@perches.com> wrote:
[]
> There are _many_ cases the console lock is held, and we don't print
> stuff immediately out to the console, and we never ensured that in the
> past. There was never a guarantee that stuff ended up on the console,
> kmsg was always and needs to be a store+forward model.

I'm less concerned with kmsg than you.
I think it's more a nicety than anything.

> > It would require all sites with continuation lines
> > be modified. Because it requires in-situ code
> > modifications, I'd prefer a cookie based approach.
>
> Well, it would be mostly for the dev_printk() stuff, which should
> ideally never be merged with stuff that could go wrong.

Perhaps that's ideal, but not practical.
printk continuations are more prevalent.

> > I think it's more flexible, allows the cookie to be
> > passed into extending functions and doesn't demand
> > (much) extra stack.
> >
> > Something like:
> > https://lkml.org/lkml/2012/4/3/231
> > https://lkml.org/lkml/2011/11/14/349
>
> Hmm, how do we manage memory allocations here? We can get around that
> somehow? It's something the common printk() must really avoid.

Well, I think the malloc costs are pretty low
and could devolve pretty easily when OOM.

cookie=NULL, directly emit.

Anyway, interesting idea, keep at it, see what
comes out of it.

cheers, Joe



\
 
 \ /
  Last update: 2012-07-11 18:01    [W:0.057 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site