lkml.org 
[lkml]   [2009]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC - printk handling more than one CON_BOOT
Date
On Tue 30 Jun 2009 19:14, Ingo Molnar pondered:
> > > Why not have a state variable that tells us whether we are in
> > > the early boot phase or not and warn about early consoles that
> > > get registered too late and real consoles that get registered
> > > too early?
> >
> > That makes sense to me. Today - there are some bootconsoles (x86
> > and sh) that accept a "keep" - still register early - but don't
> > set the CON_BOOT, so they get treated like a normal console (but
> > are hooked up before console_init()).
> >
> > This would not allow that to happen.... - is that really desired?
>
> Hm, i actually rely on 'earlyprintk=...,keep' myself sometimes.
>
> I should really have noticed that ;-)
>
> 'keep' is really useful for some of the nastiest of crashes: where
> we crash so hard and so fast that regular printk has no chance/time
> to print something useful. On more than one occasion i got the
> un-fancy early-printk stuff give me a vital clue before the kernel
> crapped up - while normal printk wouldnt.
>
> So you are right - we need an iteration over early consoles and
> shuffle the keep-ones into the real console list, right?

My limited understanding is that the only difference between a "standard"
console, and a bootconsole is the flag CON_BOOT.

boot consoles get added as normal (in register_console()), then removed from
the console list (in unregister_console()) already - don't they?



The other thing I forgot to do was update disable_boot_consoles() - that is
fixed now too.

-Robin



\
 
 \ /
  Last update: 2009-07-01 02:29    [W:0.083 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site