Re: SCSI Patches - mostly on/off-line stuff

[Douglas Gilbert <dougg@torque.net>]

Max TenEyck Woodbury wrote:
> [snip]
> 3) Add scsi force-device-online and force-device-offline
>    commands to the /proc/scsi/scsi interface.
> [snip]

This patch from Max got me thinking about hot-plugging
issues. Now there are 2 things a hotplug-tolerant scsi
(pseudo) adapter might do if it detected the removal of
a device, calls that do the equivalent of:
   1) echo "scsi remove-single-device <h> <b> <t> <l>" > /proc/scsi/scsi
   2) echo "scsi force-device-offline <h> <b> <t> <l>" > /proc/scsi/scsi


Option 1) is pretty absolute and is currently disallowed
if there are any open fds on that device. With some work 
this restriction could be relaxed.

Seen from a scsi upper level driver's point of view (e.g.
sd or sg) option 1) would be a detach(device) call. 
Taking the case of sg (a character device) what should 
it return on subsequent calls to read(), write(), 
ioctl() on a fd associated with the detached device? [My
guess: ENODEV]. How about a poll() involving such a
fd? [POLLHUP or POLLERR] And if the fd was running 
async should a SIGPOLL signal be generated by the 
detach() call? [with 'band' POLL_HUP if rt signal]. 
Most likely apps would like to be informed of such 
events. I'm not clear on what a block special such 
as sd should do in response to a premature detach() 
on an open fd.


Option 2) allows for the device to be brought back
online with its state being maintained. It could be
nasty (for the scsi subsystem) if a USB mass storage 
device was pulled out of one USB port and placed in 
another. 

Currently there is no mid-level call into upper level 
scsi drivers to indicate that the state of 'offline' 
has been flipped. [Perhaps there should be to allow 
upper level drivers to generate signals.] Sg doesn't 
test the state of a device's offline bit before it 
tries to dispatch a scsi command to the mid level. 
[Perhaps it should.] Same questions apply as to what 
sg and sd should do. Another option in this case is 
that system commands (e.g. read() and write()) are 
put into a wait state for up to a minute, say, to 
give the device a chance to come back online.


Doug Gilbert

_______________________________________________
Linux-hotplug-devel mailing list
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel