From mboxrd@z Thu Jan 1 00:00:00 1970 From: Douglas Gilbert Date: Thu, 11 Jan 2001 21:56:38 +0000 Subject: Re: SCSI Patches - mostly on/off-line stuff Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 " > /proc/scsi/scsi 2) echo "scsi force-device-offline " > /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