Alan Stern wrote: >
Matt's current proposed patch has the USB LLDD calling scsi_unregister_host() (because the device is respresented as an emulated
A LLDD should and must *not* call scsi_unregister_host(). This brakes all hierarchy.
Let's not make a distinction between a USB LLDD and any LLDD wrt hotplugging, else we'll have a big mess and plenty of code duplication. When a device gets unplugged and the LLDD notices it, it will set the device to off in its own tables, call scsi_set_device_offline(dev) and from that point on *if* any commands for that device step in through queuecommand() method, they will return with the appropriate error. scsi_set_device_offline(dev) will do whatever it has to do, which IMHO is to, as Doug suggested, start error recovery (i.e. less code, less code duplication in LLDD), and call an upper level hook. * * Though I'm not quite certain where that error recovery should be started... Maybe that upper level hook after doing whatever it has to do, it will start the error recovery, or maybe it doesn't matter for now. But, an upper level hook call is, IMHO, mandatory for many reasons. Now, here we have the alternatives: scsi_set_device_offline() calls slave_destroy(), or slave_destory() is called later on when upper level structs has been cleaned. In fact, it wouldn't matter, if SCSI Core takes over error return, via post scsi_set_device_offline(dev) call.
host adapter) when it learns that the device is gone. Provided that routine doesn't block for very long, provided it handles all the details of hotplug notifications, and provided it guarantees that after it returns there will be no more calls to the emulated adapter, I don't see any problem. The LLDD can go ahead and remove all records of the former device, secure in the knowledge that all pointers to data structures and entry points have been erased.
A LLDD shouldn't be so concerned with ``blocking'', unless *it* sets timers on calls to an upper level like SCSI Core functions. A LLDD has quite a clean and clear function it's supposed to do. -- Luben ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
