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

[<Oliver.Neukum@lrz.uni-muenchen.de>]

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 <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.

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