Messages in this thread | | | Date | Wed, 10 Jun 2015 11:04:20 +0200 | From | Borislav Petkov <> | 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. --
| |