[Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Josh Triplett]

On Thu, Jul 21, 2016 at 11:31:05AM +0100, David Woodhouse 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.

I've run into various cases where "console=ttyS0,115200" didn't produce
any serial output at all, but "earlyprintk=ttyS0,115200,keep" did.
Perhaps "earlyprintk" expects less from the serial port than "console"
does, but that suggests that the differences involve more than just how
early the driver can work.