On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote: > > * Jamie Lokier <jamie@xxxxxxxxxxxxx> 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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
