> > 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? > > This sounds like a good option. Don't confuse "/dev/console" and "the console device" in printk terms. The two are not the same thing and the latter is subject to stuff like redirection. > thing, but it should be possible to just do something like > > static struct tty_driver console_driver; No - a console device can fail to open so you need to try the next one in that situation. Some platforms use this feature. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
