[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150610090420.GA24882@pd.tnic>
Date: Wed, 10 Jun 2015 11:04:20 +0200
From: Borislav Petkov <bp@...e.de>
To: Alexander Kuleshov <kuleshovmail@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mark Rustad <mark.d.rustad@...el.com>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH v11 3/5] x86/earlyprintk: Allocate early log_buf as early
as possible
On Tue, Jun 09, 2015 at 11:37:27PM +0600, Alexander Kuleshov wrote:
> Borislav, I'm really not sure too, that using of printk to update
> log_buf with the earlyprintk is a right correct here.
Yes, so this whole approach and what you're trying to achieve
seems kinda confusing and wrong. First of all, the early_printk()
machinery prints to a special console driver, i.e., I'm looking at the
registration fun in setup_early_printk().
So using early_printk() to print to dmesg is the wrong tool for the
job. Actually, if you want to do that, you can just as well use plain
printk() and try to make it work much earlier. Which is basically what
you did by using the printk_func per_cpu ptr, but that was hacky and
ugly.
In order to do that right, you need to slow down first, think hard
and look hard and long at printk(), log_buf, the statically allocated
smaller __log_buf and the whole machinery behind it. Whether it can be
used that early or not. And to explain why it can or why it cannot in
your commit messages. Then test your stuff a *lot* on the hw you have
access to because printk() is not a joke. It needs to be very reliable
and to work.
If you don't do your homework and expect other people to do it, you will
have a lot less success with your patches.
I sincerely hope that helps.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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