From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Thu, 11 Jan 2001 22:43:58 +0000 Subject: Re: SCSI Patches - mostly on/off-line stuff Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Thu, 11 Jan 2001, Douglas Gilbert wrote: > 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. It need not be effective at once. Most drivers would probably happy with a flag/call to signal a vanished device and a callback once all fds are gone to free the memory associated. In fact that would be preferable. It's not a drivers business to know what to do in this case. A driver's duty should be to report that condition. > 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 Could be confusing, but it's probably right. > as sd should do in response to a premature detach() > on an open fd. As a suggestion: Wait for a few minutes and return errors to open() only. After a timeout return errors. If it is reattached some kind of checksumming might be a good idea. > Option 2) allows for the device to be brought back > online with its state being maintained. It could be How ? Is there a way to know internal state has been maintained. For sd it might not matter, for sg a disconnected device must be considered gone for good by default. Those drivers with these problems probably register themselves as host controllers for each device/bridge. These register/unregister calls need the same attention as above. > 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. That choice must be left to the high level drivers. Do really want to use off-line for that ? Regards Oliver _______________________________________________ Linux-hotplug-devel mailing list Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel