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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
