aboo wrote:
> Also, I am facing another challenge which I wanted to ask. If the kernel or
> user space opens a scsi device, there is no healthy way of identifying if a
> scsi device is open or not. The struct scsi_device does not have a field. I
> can see a openers field in the scsi_disk structure inside sd.c. I can see it
> incrimenting in sd_open(). What is the best to way to identify if a
> scsi_device id open by kernel (mount or volumes manager) or use application
> (fsck or dd)? When a destroy a scsi_host, it kills all the scsi_devices
> associated with it irrespective of those devices are open or not. Any
> thoughts?
I thought about this myself too while working on the sbp2 driver. This
is a low-level driver from the SCSI perspective and a high-level driver
from the FireWire perspective. It was possible to unload a FireWire
low-level driver which provided the interconnect to a SBP-2 LU while
that LU's device file was in use --- with the obvious result of sudden
loss of connection. As a simple solution, sbp2 now blocks unloading of
the FireWire low-level driver as long as it is logged in into a SBP-2
target (i.e. independent of actual usage of the device; longer than
actually necessary).
My idea for a more fine-grained solution was:
- Add something like .slave_get(sdev) and .slave_put(sdev) to the
scsi_host_template.
- Let scsi_device_get() call shost->hostt->slave_get() if it exists.
Let scsi_device_put() call shost->hostt->slave_put() if it exists.
- In the two new hooks, an LLD can get and put whatever transport- or
interconnect-related resources it needs, per LU.
However I never found this matter pressing enough to post a respective
patch here. From my perspective, it would have only been justified if
other LLDs besides sbp2 would have profited from it, and I was too busy
elsewhere to research that.
--
Stefan Richter
-=====-=-=== ---= =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
