Re: [Announce] Linux-tiny project revival

Kyle Moffett
2007-09-21T22:59:38Z

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