[Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Andy Lutomirski]

On Tue, Jul 26, 2016 at 7:40 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Thu, 2016-07-21 at 08:05 -0700, Andy Lutomirski wrote:
>> On Thu, Jul 21, 2016 at 3:31 AM, David Woodhouse <dwmw2 at 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),
>
> We had bootx on PowerPC which worked from extremely early.
>
>> 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.
>
> Me no like.
>
> That makes even *less* sense for early boot than it does during later
> runtime. Because even *more* of the 'we crash' scenarios during early
> boot are going to be uncontrolled "oh shit" happenings, not "oh dear,
> it looks like we're going to crash so let's helpfully dump out all the
> console messages before we do so".

I only meant in the cases where we're currently silent.  If we boot
with "quiet" and we panic, couldn't we at least try to flush out the
printk buffer onto the early console?  Currently we just sit there
with a blank screen.  (I debugged a case exactly like that last week.)

--Andy