Re: [Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Andy Lutomirski <luto@amacapital.net>]

On Thu, Jul 21, 2016 at 3:31 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2016-07-21 at 07:59 +0200, Hannes Reinecke wrote:
>> > If we do all this stuff, can we also try to clean up earlyprintk a
>> > bit?  The whole earlyconsole mechanism is a mess, and switching over
>> > to the non-early console is only somewhat functional.  I'd love to see
>> > this all simplified: before there's any console at all available, just
>> > buffer messages.  Then, when a console shows up, write the buffer out.
>> > Then earlyprintk can work just like regular printk.
>> >
>> Begging the question how one would debug failures during that time.
>> The current earlyprintk stuff is at least able to print out _something_,
>> so that you have some idea what went wrong.
>> Without that things will become _really_ hard during board bringup.
>
> No, you don't actually *delay* the console output. You still register
> the console as soon as you physically can, but you just don't have all
> that nasty special-casing of the "earlyprintk" nonsense; you just make
> sure the standard console output is capable of working as early as you
> need it to.

Agreed.

If we could convince fbcon to work early (which it really ought to),
then we could get rid of the extra graphical console implementations
floating around, e.g. the mediocre one sitting in the earlyefi console
code.  We could also get rid of the handover problem when we
initialize the "real" efifb -- all we'd have to do is initialize efifb
very, very early, and I see no reason at all that we can't do that.
(Well, I see one silly reason: if we initialize it before PAT, then we
could end up with a UC mapping instead of WC, and I'm not sure that
the x86 PAT code is smart enough to change the mapping type after the
fact.  This could relatively easily be special-cased for efifb by
teaching it to unmap and remap itself after PAT init, or we could try
to initialize PAT earlier.)

But doing this really nicely does tie in to the async printk
discussion for a different reason.  I think that we should always
initialize the obvious "early" consoles that can be cleanly enumerated
early (e.g. EFI).  What we shouldn't do by default is *display*
anything to them unless we crash, because the distro people want a
clean boot to look pretty.  ISTM the condition for flushing the async
printk buffers could be the same as the condition for actually writing
to pre-VT consoles.

--Andy