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

[David Woodhouse <dwmw2@infradead.org>]

On Tue, 2009-04-21 at 00:13 -0700, David Brownell wrote:
> 
> Stepping back a moment from "how" to make sure "what" is agreed on.
> 
> I think I see three scenarios here:
> 
>  - Classic PC or server, where there's a meaningful console;
> 
>  - Deeply embedded systems, where there isn't;
> 
>  - Development stages of "deeply embedded", where there *may* be one.
> 
> If that's correct, then async_synchronize() isn't a full answer...
> 
> I think a fair number of cases can be papered over with a serial
> console with no hardware flow control, which isn't hooked up to
> anything.  Maybe the board needs a test/development jig to get one;
> without it, the "console" bits spill out into the aether.  Linux
> can dump bits to ttyS0, which will act like /dev/null.
> 
> But the problem case here seems to be one where such un-hooked-up
> serial ports are not realistic options.  Which is why the regression
> in USB console functionality has been troublesome.

We can provide un-hooked-up /dev/console though. Rather than just
failing to open it, why can't we make __tty_open() give you a dummy tty
driver which is basically equivalent to /dev/null? And then 'replace' it
with the real console driver if/when that later gets registered? The
latter will be a high-caffeine job, but surely not impossible?

The kernel output is going to be spewed when a console registers with
CON_PRINTBUFFER anyway, and if we printk a warning about userspace
console output being lost, that ought to be good enough to notify the
user that something may have been lost. For bonus points, we could even
make that 'dummy' tty driver buffer a limited amount of userspace
output, maybe.

If userspace cares, let _it_ wait, by using an ioctl to see what tty
device it's _really_ attached to.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation