[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090422053518.GA11055@cuplxvomd02.corp.sa.net>
Date: Tue, 21 Apr 2009 22:35:18 -0700
From: David VomLehn <dvomlehn@...co.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Jamie Lokier <jamie@...reable.org>, Ingo Molnar <mingo@...e.hu>,
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
By now, pretty much everone is probably up to speed on what the USB folks are
telling us:
There is no way to avoid using some sort of timeout to decide
whether the console is ever going to appear.
So:
1. We want the minimum timeout possible so that headless systems will
not be delayed any more than is necessary to detect that no console
is available.
2. As I understand it, USB devices don't generally come with any
guarantee what the maximum time to initialize will be.
Therefore, as far as I can see, this means that we can't empirically
determine an appropriate timeout until we know what USB devices are
connected to a particular system. This, in turn, means that any default
timeout we might choose will have to have a command line parameter to
override it.
Naturally, we want to help a user determine as easily as possible just how
long it took to detect whatever serial device they may want to use so that
they can set the timeout so the system will boot as quickly as possible when
being used in a headless mode. This probably means picking a stable point
from which to start measuring the timeout, as well as printing how long it
took to detect the console, if there was one.
An open question is whether we want to wait for all possible consoles or
whether we can proceed with as few as one.
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