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

[Alan Stern]

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