On Mon, 4 May 2009 10:30:06 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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? take a ref in the driver_probe_done() sense, and release it when you know you're done probing.... at that point all existing infrastructure will just work. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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
