On Sun, 3 May 2009, Arjan van de Ven wrote: > > Perhaps with some enterprise systems, it is preferred to have the > > system fail with an explicit error message rather than wait > > indefinitely... > > actually, in an enterprise system, you want to reboot. > The bootloader might boot a different kernel the next time > that is known to work. > (for example, the current kernel might have been booted with the "once" > grub option) Which makes it imperative that the system knows when all the block devices have been probed, so it can stop waiting. > > How does Arjan's async boot system tell use when all discovery is > > complete? AFAICS, it only tells you when all its async tasks are > > finished. But device discovery and registration sometimes use other > > asynchronous techniques which Arjan's code is unaware of. > > Examples: the USB khubd thread, the USB mass-storage scanning thread, > > and the SCSI async-scanning thread. > > for normal device probing we already have infrastructure though... > wait_for_device_probe, driver_probe_done and friends... > (the scsi scanning thread is being converted to the async > infrastructure btw) > > do we need to invent more ? I suppose the usb-storage scanning thread could also be converted to the async infrastructure, although I haven't heard of anybody working on it. But the USB hub driver's thread (khubd) cannot be converted. It is central to the discovery of USB-based block devices. How would you handle that? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
