linux-kernel - Re: RFC - printk handling more than one CON

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200906302029.36962.rgetz@blackfin.uclinux.org>
Date:	Tue, 30 Jun 2009 20:29:36 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"Ingo Molnar" <mingo@...e.hu>
CC:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, "Paul Mundt" <lethal@...ux-sh.org>
Subject: Re: RFC - printk handling more than one CON_BOOT

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/