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.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
