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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
