From: David VomLehn <dvomlehn@cisco.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jamie Lokier <jamie@shareable.org>, Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux USB Mailing List <linux-usb@vger.kernel.org>,
Linux Embedded Mailing List <linux-embedded@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Wait for console to become available, v3.2
Date: Tue, 21 Apr 2009 22:35:18 -0700 [thread overview]
Message-ID: <20090422053518.GA11055@cuplxvomd02.corp.sa.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0904211457150.3986-100000@iolanthe.rowland.org>
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
prev parent reply other threads:[~2009-04-22 5:35 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-20 23:40 David VomLehn
2009-04-21 6:43 ` Ingo Molnar
2009-04-21 7:13 ` David Brownell
2009-04-21 8:03 ` Ingo Molnar
2009-04-21 17:11 ` David Woodhouse
2009-04-21 17:29 ` David VomLehn
2009-04-21 17:37 ` Linus Torvalds
2009-04-21 17:59 ` David VomLehn
2009-04-21 17:41 ` David Woodhouse
2009-04-21 17:31 ` Linus Torvalds
2009-04-21 19:25 ` Alan Cox
2009-04-21 23:17 ` David VomLehn
2009-04-22 8:25 ` Jamie Lokier
2009-04-22 9:11 ` Alan Cox
2009-04-22 10:39 ` Jamie Lokier
2009-04-21 13:35 ` Arjan van de Ven
2009-04-21 13:50 ` Ingo Molnar
2009-04-21 14:05 ` Jamie Lokier
2009-04-21 14:26 ` Ingo Molnar
2009-04-21 14:37 ` Alan Cox
2009-04-22 8:22 ` Jamie Lokier
2009-04-22 9:13 ` Alan Cox
2009-04-21 16:42 ` David VomLehn
2009-04-21 14:36 ` Alan Stern
2009-04-21 16:52 ` David VomLehn
2009-04-21 19:09 ` Alan Stern
2009-04-21 23:08 ` David VomLehn
2009-04-22 15:40 ` Alan Stern
2009-04-22 20:54 ` David VomLehn
2009-04-22 21:08 ` Alan Cox
2009-04-22 21:24 ` Alan Stern
2009-04-24 0:35 ` David VomLehn
2009-04-24 19:20 ` Alan Stern
2009-04-24 21:32 ` David VomLehn
2009-04-24 22:19 ` Jamie Lokier
2009-04-24 23:10 ` David VomLehn
2009-04-25 1:41 ` Jamie Lokier
2009-04-25 3:11 ` Alan Stern
2009-04-26 19:52 ` Jamie Lokier
2009-04-26 21:20 ` Alan Stern
2009-04-26 21:37 ` Jamie Lokier
2009-04-26 22:36 ` Kay Sievers
2009-04-26 23:12 ` Jamie Lokier
2009-04-26 23:23 ` Kay Sievers
2009-04-26 23:46 ` Jamie Lokier
2009-04-26 17:55 ` David VomLehn
2009-04-22 5:35 ` David VomLehn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090422053518.GA11055@cuplxvomd02.corp.sa.net \
--to=dvomlehn@cisco.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=jamie@shareable.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®