Alan Stern wrote:
So I need a
way to know whether anything is mounted on a device below a SCSI host.
Actually I have been thinking of something related for a while but
didn't send a patch yet. Consider this:
[include/scsi/scsi_host.h]
struct scsi_host_template {
...
+ int (* slave_sdev_get)(struct scsi_device *);
+ void (* slave_sdev_put)(struct scsi_device *);
...
}
[drivers/scsi/scsi.c]
int scsi_device_get(struct scsi_device *sdev)
{
+ int err = 0;
+
if (sdev->sdev_state == SDEV_DEL)
return -ENXIO;
if (!get_device(&sdev->sdev_gendev))
return -ENXIO;
/* We can fail this if we're doing SCSI operations
* from module exit (like cache flush) */
try_module_get(sdev->host->hostt->module);
- return 0;
+ if (sdev->host->hostt->slave_sdev_get)
+ err = sdev->host->hostt->slave_sdev_get(sdev);
+ if (err) {
+ ...some ifdef'd module_put stuff...;
+ put_device(&sdev->sdev_gendev);
+ }
+ return err;
}
and equivalent additions to scsi_device_put().
Example usage:
[drivers/ieee1394/sbp2.c]
+int sbp2_slave_sdev_get(struct scsi_device *sdev)
+{
+ struct sbp2_lu *lu = (struct sbp2_lu *)sdev->host->hostdata[0];
+
+ if (!try_module_get(lu->hi->host->driver->owner))
+ return -ENOMEM;
+ return 0;
+}
and an equivalent sbp2_slave_sdev_put(). These examples would prevent
unloading ohci1394 while somebody has mounted a filesystem on a device
driven by sbp2, or otherwise opened or referenced that device. (At the
moment sbp2 unintelligently gets the host->driver->owner as long as it
is logged in into a device. This is somewhat necessary because there
are unrelated drivers in the ieee1394 stack which when unloaded with
modprobe would cause ohci1394 to be unloaded too.)
You could use slave_sdev_get()/ slave_sdev_put() callbacks in
usb-storage to do an own bookkeeping of references there.
(Since I haven't looked at your other current work, all of the above may
be utterly besides the point...)
--
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