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

[David VomLehn <dvomlehn@cisco.com>]

 Tue, Apr 21, 2009 at 10:37:41AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 21 Apr 2009, David VomLehn wrote:
> > 
> > What in the world are users going to do when they see a message about
> > output being lost? There is no way to recover the data and no way to
> > prevent it in the future. I don't think this is a good approach.
> 
> Sure there is. The console messages are saved too, so doing 'dmesg' will 
> get you all the data that was generated before the console went on-line.
> 
> We _already_ lose data in that sense (although we could replay it for the 
> first console connected - maybe we even do, I'm too lazy to check).

There are two different things coming out on the console, kernel log buffer
messages and userspace output to /dev/console. Kernel log buffer output
is replayed for each console as it connects. There might be quite a bit of
it, but it is pretty much the same from boot to boot, so the guy working on
the kernel, me, can tune the size of log_buf pretty easily. This is not
the problem.

The problem is the userspace output to /dev/console. I work in the embedded
space and my box does not simply throw up a few windows and wait placidly for
the user to do something. Instead, it immediately starts running a whole bunch
of software with a whole bunch of startup messages. In short order, I am
running over 300 threads. I have no control over how much output comes out,
I have no idea how much kernel memory to allocate for this, and I'm quote sure
it's enough that I wouldn't want to waste that much space even if I did. No
matter what, this looks like we'd need a new tunable for the size.

And then, what happens if I *never* get a console, because one isn't plugged
in? This happens a lot in the embedded world. How long am I supposed to keep
around this big chunk of buffered data? Sounds like I need *another* tunable.
Yuck.

> 			Linus