On Wed, 22 Jun 2005, Luben Tuikov wrote: > The notify event can "travel" right behind flush-cache and "close doors" > behind. (since it travels from the application client to the device) Are you sure about that? One way to generate such a notify event is to rmmod the LLDD. The event is then generated by the LLDD and it travels up to the midlayer, by way of scsi_remove_host. You seem to be saying that there should be a separate API for the LLDD to notify the midlayer that it is about to be unloaded. > Yes indeed: the proper order is: > * lock the front door, > * empty all rooms, > * call scsi_remove_host(). > > This is on _hot-unplug_ since the event came from the SDS. > In the event of a notified unplug, the event would be known to > SCSI Core _before_ it is known to the LLDD, so SCSI Core would > lock the "fence gate", send flush-cache (which would seem as any > other command to you), then wait for that to return (which would > mean no other commands are pending, since this was the last command > to be sent after locking the "fence gate") and then it would > call scsi_remove_host() or whatever appropriate. Currently there is nothing like your "fence gate", although there should be. > > usb-storage. I don't know how any other hot-unpluggable LLDDs will handle > > cancellation during unplug. > > In case the LLDD is implemented properly, just doing nothing should suffice. ;-) So should the midlayer no longer try to cancel outstanding commands when a host is removed? Can it rely on the LLDDs to do so? Alan Stern - : 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
