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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

On Thu, 2016-07-21 at 08:05 -0700, Andy Lutomirski wrote:
> 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),

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".

We already have *really* early command line parsing; we can use that to
determine the console loglevel if we need to. No need to be printing
debug messages to the console unconditionally and upsetting the
graphical boot...

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]