Re: [Announce] Linux-tiny project revival

[Kyle Moffett <mrmacman_g4@mac.com>]

On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
> On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
>> 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.
>
> A negative is that lockup conditions swallow partial messages.

But typically you don't care if a "partial line" gets swallowed  
regardless.  The only reason people really use partial lines is when  
they're accumulating a variable number of things into a single line  
and so a single printk() won't do, and in that case it's really not a  
problem to "lose" the first half of the line in event of a crash.   
And hell, if it matters that much you could just make the qprintk_ 
{kmalloc,percpu,irq} functions chain the qpk variables on a little  
linked list and stuff an smp_wmb() in the _gprint() function after  
writing the text and before writing the size.  That way any panic  
could very carefully look at the messages being queued during the  
crash and attempt to write out partial buffers.

It's a technique which in combination with looking at the first 3  
characters of the arguments to printk() would let you elide 99% of  
the non-critical printks pretty easily while only needing to change  
the much smaller proportion of the printk()s which are partial  
lines.  Furthermore it's pretty easy to grep for the partial-line  
printk()s and you can even have it emit warnings when you hit a  
partial-line printk() (it doesn't start with "<"[0-9]">") in -mm to  
help fix up the last few users and keep people from adding new ones.

Cheers,
Kyle Moffett