On Sat, 2008-05-03 at 16:42 -0400, Alan Stern wrote: > Of even more interest and relevance is this thread: > > http://marc.info/?t=109630920600005&r=1&w=2 > > In one of the messages in that thread, James Bottomley wrote: > > ------------------------------------------------------------------------ > Right. scsi_remove_host tells the mid-layer that it's OK to trash all > inflight commands because you removed all their users before calling > it. It also tells us that you won't accept any future commands for > this > host (because you'll error any attempt in queuecommand). > ------------------------------------------------------------------------ > > Later on Mike Anderson asked: > > ------------------------------------------------------------------------ > Clarification. James, are you indicating that there needs to be a new > scsi mid api that performs similar function to scsi_remove_host expect > does not cancel commands? > ------------------------------------------------------------------------ > > There was no real answer and things were left hanging. > > So I guess part of what I'm asking is whether the situation is now > significantly different. Not really ... there's never been cause to make it so. At the beginning of the hotplug debate it was thought there was value in a wait for unplug event ... some PCI busses have a little button you push and then a light lights up to tell you everything's OK and you can remove the card. After a lot of back and forth, it was decided that the best thing for the latter was for userland to quiesce and unmount the filesystem, application or whatever and then tell the kernel it was gone, so in that scenario, the two paths were identical. I don't think anything's really changed in that regard. James -- 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