Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5

Alan Stern
2009-05-04T14:30:06Z

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