[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPXgP117sDoiuA-i3LWFPnj+VN5BbOQrYGM8KXYCqGSan7ZZMg@mail.gmail.com>
Date: Wed, 27 Jun 2012 13:12:27 +0200
From: Kay Sievers <kay@...y.org>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Ingo Molnar <mingo@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>,
Lennart Poettering <lennart@...ttering.net>
Subject: Re: cosmetic printk() issue with lockdep warning in arch/x86/kernel/alternative.c
On Wed, Jun 27, 2012 at 1:06 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Wed, 2012-06-27 at 12:49 +0200, Kay Sievers wrote:
>> All we want is a reliable printk
>
> We too, but we define reliable differently. I want printk() to dump data
> ASAP so that it has better chance to get out of the system and onto my
> console in case of a crash. I don't give a rats arse about interleaved
> text, any text is better than no text.
Sure, I fully understand that this is useful.
> So if you go add separate buffers in there that will delay writing text,
> you're actively destroying printk().
>
> Any change that makes it harder to get text out is bad.
The text is always flushed immediately for full lines, there is no
change at all. Since yesterday, continuation lines (which are
buffered) are flushed immediately to the console too.
I don't think there will be a substantial difference anymore to the
old behaviour, but we still get reliable records stored in the kmsg
buffer.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists