Hi Doug
> Actually, I would have both complicated and simple transports call
> scsi_set_device_offline() and for two reasons. 1) you have to provide
> that function for simple drivers so duplicating other detection code in
> the scsi completion handler is a waste. 2) pretty much all transports
> will learn of the device being offline while they are in their interrupt
> handler and should already be holding the lock for the device, which means
This is not the case for USB and IEEE1394. I am not sure about PCMCIA.
We are in context of a kernel thread while we learn about device removal.
> that calling scsi_set_device_offline() won't race with scsi_request_fn()
> which also needs the device lock (which in reality is the host lock).
> Saving this race is convenient enough IMHO to warrant saying that's the
> way things need to be.
>
> > > scsi_set_device_offline(dev) calls a high-level kernel function to
> > > start higher level things (block queue cut off, etc) which *may* need
> > > to be done.
>
> No, scsi_set_device_offline() schedules the error handler thread for that
> host to be woken up.
>
> > How do you differentiate between real failure and device removal?
>
> We don't, and we shouldn't. Device removal *is* a real failure.
Well shouldn't a device removal remove the device as a logical
entity and a failure should not?
> If the LLDD is the type such that it knows the device is gone (aka, in my
> driver if I get a selection timeout then I know something is fishy and can
> proceed from there, iSCSI may not be so lucky), then it has one of two
> choices. 1) it may flush any commands that it can out of the hardware and
> return them immediately with the same error condition as the one that it
> is already returning. 2) it can sit and wait for the commands to timeout
> one by one if that's what it wants. Since the device has already been
> marked offline by scsi_set_device_offline() and the error handler thread
> is already scheduled to run for the device, 2 is probably the easiest
> thing for the driver to do. The error handler will call the abort/reset
Again not for USB and IEEE1394. We'd have to wait for the error handler
to finish. Doing it ourselves is easier.
> Once all the commands are gone and no more are arriving, then if, and only
> if, someone actually removes the device from the scsi subsystem (maybe
> hotplug manager or something) then you will get the typical
> slave_destroy() call to tell you that it is safe to release all resources
> related to this device. Otherwise, the device will hang around as an
> offline device until someone does echo "scsi-remove-single-device a b c d"
Eek. That part I must strongly object to. The device is physically gone.
Ever bothering the LLDD with it is very inconvinient.
> > /proc/scsi/scsi to remove it.
>
> Basically, as I see it, we need a new function scsi_set_device_offline()
> that marks the device offline, we need an offline check in
These functions are needed for a whole bus as well. USB needs it.
> As far as plugging back in, the answer is simple. Until the old instance
> is dead *and removed* a new one can't be added at the same ID, aka you
> simply ignore the hot plug until the hot remove has completed.
What do you mean? It is dead because it is removed. How can a device be
anything than dead if it has been unplugged? Please elaborate.
And who should ignore a hot addition, the LLDD or SCSI core.
If the former, again I must object.
Regards
Oliver
-------------------------------------------------------
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
