linux-kernel - Re: Wait for console to become available, v3.2

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]

Date:	Tue, 21 Apr 2009 16:17:28 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	David Brownell <david-b@...bell.net>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Linux Embedded Mailing List <linux-embedded@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wait for console to become available, v3.2

On Tue, Apr 21, 2009 at 08:25:01PM +0100, Alan Cox wrote:
> > Anybody want to try it? Just make it ignore any IO if there are no 
> > registered consoles. The patch shouldn't even be all that big, I suspect.
> 
> It will work, but on its own it won't actually fix the problem people
> have, which is wanting to wait for a real console to appear. Extending it
> to sleep (if not O_NDELAY) and loop back through the list when the list
> changes would however do the trick, that or a tty device that buffers
> then spews into the real device when it appears.
> 
> Definitely the right path, and we almost have every tty device in
> existance containing a struct tty_port, at which point it gets even
> cleaner.
> 
> The printk() console needs to buffer up data and replay it but we already
> pretty much do what is needed even for vt consoles because the fb isn't
> ready before the first printk.

We're already good on printk, the size of log_buf is configurable and log_buf
is dumped to each console as it gets registered. Even then, printk output is
not an especially big issue since you have dmesg to get to anything you
might have missed.

Other the other hand, userspace output is not buffered and has the potential
to be much larger. Any approach that buffers it risks either truncation or
gobbling up memory. There is also the human factors issue that users will
pretty much ignore printk output because they don't particularly understand
it. They understand, and expect to see, the output they generate. I'm pretty
sure they won't like for it to go missing under mysterious circumstances.

David VomLehn
--
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/