Date:	Tue, 21 Apr 2009 09:42:23 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jamie Lokier <jamie@...reable.org>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 04:26:27PM +0200, Ingo Molnar wrote:
> 
> * Jamie Lokier <jamie@...reable.org> wrote:
> 
> > Ingo Molnar wrote:
...
> > > What i'm saying is: instead of "wait 2000 msecs, maybe it works 
> > > out" hack, there should be a proper sleep+event based approach 
> > > to the same. With perhaps a _timeout_ for the "no console 
> > > arrived" negative case as well. (which timeout can be set to 
> > > zero in the "I _know_ there's no console around".)
> > 
> > Isn't the proposed code doing exactly that?  It sleeps waiting for 
> > a console, with a timeout of X msecs.  If a console arrives before 
> > that, doesn't it wake immediately?
> 
> Yes - except that the timeout is aspecific. I.e. we'll time out even 
> if the delay happens not due to a device arriving too late (or not 
> arriving at all), but due to some earlier init step taking an 
> unexpectedly long time.

I agree, but this is also a pretty good description of why things actually
worked before--it just so happened that work intervening between starting
USB enumeration and the opening of /dev/console was long enough that
USB serial devices were initialized. So, no, it's not good. But it's a
pretty close equivalent to previous behavior.

That being said, I'm also thinking that the timeout interval should start when
bus initialization is started. The point between the start of USB
initialization and when a particular device is initialized should be, as
a practical matter and for a particular hardware configuration, more or
less constant, and so more predictable for users.

Basing the wait interval from the start of bus initialization has the
additional advantage that we can also implement similar timers, such as one
for network devices, off the same base time. Since the ip= kernel parameter
is similarly broken, I've been looking at what it would take to get it
working again, too. Or at least, with deference to the constraints of USB and
acknowledging the importance of luck, working as well as it used to.

> Also, if we end up doing this - the patch, as proposed right now, 
> appears to add a default 1000 msecs sleep to every __tty_open() 
> call:
> 
> +config PRINTK_CONSOLE_WAIT
> +       int "Default number of milliseconds to wait for console device"
> +       default 1000
> 
> Does this only delay init during a console-less bootup - or are 
> there other later apps that might trigger the delay?

Sleeping and polling for an event, rather than using a suitable notification
primitive, causes me existential anguish. Seriously, I *hate* code like that
and systems that make you do such brutish things. Linux is not one of those
throwbacks, so as soon as a console shows up, we continue. Thus, we only wait
the whole interval if the console device is very slow to initialize or if
there is no console device, at all.
--
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/

Powered by blists - more mailing lists