[lkml]   [2009]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Wait for console to become available, v3.2
    On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote:
    > * Jamie Lokier <> 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:
    > + 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

     \ /
      Last update: 2009-04-21 18:49    [W:0.027 / U:5.112 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site