On Sat, 2 May 2009, James Bottomley wrote: > OK, so in your scheme, I get why console devices: they need to be > present early before we start dumping console output otherwise it can > get lost. > > However, I don't see the need for either network or block. > > For network, the only early discovery use is net root (which can be done > fully asynchronously) Are you referring to the "rootwait" kernel parameter? Is there a reason why this is a boot-time parameter instead of always being set? I mean, under what circumstances would you _not_ want to wait until the root device is present? > or net console (which I think can be supplied a > raft of information and isn't usually expected to be up by early boot > because of the TCP stack dependence) neither of which is a compelling > use case. Are you sure the real reason it isn't expected to be up isn't the lack of a mechanism of the type being proposed? > Block, likewise, is a udev type discovery: We can specify the root by > some type of ID and we can wait until that is found, rather than have an > elaborate system to check when discovery is finished, which is the only > benefit this code seems to provide. The real benefit of knowing when discovery is complete is that it tells you when to give up and stop waiting. However I have to agree that in the case of the root device, there really isn't much point in giving up. Perhaps with some enterprise systems, it is preferred to have the system fail with an explicit error message rather than wait indefinitely... > What I'm getting at is that I don't see the benefit of this in the light > of Arjan's async boot system, which can also tell us when all discovery > is complete ... what added benefit am I missing here? 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. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
