RE: SCSI Patches - mostly on/off-line stuff (SBP-2 hot-plug comme

[James Goodwin <jamesg@Filanet.com>]

Hi,

Just to follow up with a bit about the current IEEE-1394 SBP-2 driver
implementation... and a few thoughts...   ;-)

> [Bob Frey] To help answer Eric's question about types of events that need
to be
> handled, for 1394 all device (node) IDs may change after a bus reset
> which automatically occurs every time a device is added or removed and
> for all 1394 host adapters generates an interrupt. Compare to 
> parallel SCSI
> where there is no automatic notification (or detection) of a 
> device being
> removed and the SCSI host adapter may optionally interrupt 
> for a bus reset.
> For 1394 an OS must reference device GUIDs to determine a 
> mapping from old
> device ids (pre-bus reset) to new (post-bus reset) device 
> ids. So event
> driven rescanning is definitely needed for 1394. 1394 also has a
> generation count which if passed to upper software layers and always
> included in requests to the lower layer can be used by the lower layer
> to validate requests. For other busses this generation count 
> would have
> to be manufactured (e.g. maybe for parallel SCSI increment a 
> counter after
> a bus reset).

Good description... and all of this is currently handled in the SBP-2 driver
and IEEE-1394 driver stack. We maintain a mapping between the IEEE-1394 GUID
(globally unique ID), IEEE-1394 node ID (which can change with each bus
reset or reconfiguration), and the SCSI ID. We maintain an association
between the "virtual" SCSI ID reported to the SCSI stack and the GUID, so
that as IEEE-1394 devices are hot plugged or unplugged other devices do not
"move around" (change SCSI IDs). 

We also deal with clearing any unit attentions in the SBP-2 driver itself
(so that a new hot plug does not affect other attached SBP-2 devices).

All of the IEEE-1394 related bus scanning and mapping to SCSI IDs is taken
care of by a kernel thread in the SBP-2 driver which is event driven (e.g.
when bus reset/reconfiguration occurs).

Currently, for the scsi stack to "pick-up" any hot added or removed
IEEE-1394 devices, we must use the proc fs interface (scsi
add-single-device, scsi remove-single-device).

> [Bob Frey] So I think rescanning should occur in the kernel 
> automatically after every
> bus reset for every different kind of peripheral bus. Every 
> peripheral bus,
> even parallel SCSI, I think has a bus reset: parallel SCSI, 
> FC, 1394 - yes,
> ATA - ?, others - ?

From an SBP-2 driver perspective, we do not necessarily need (or want) a
complete scsi bus rescan when a bus reset/reconfiguration is detected. The
SBP-2 driver knows which devices have been removed and which have been
added, and this can be handled by calls equivalent to scsi add-single-device
or remove-single-device. Also note that for the SBP-2 driver these calls
would be made by a kernel thread.

But, this could probably also be dealt with by having the low-level driver
simply report that a bus reset has occured, letting the scsi mid-layer do a
full rescan and deal with device addition and removal (if anything has
changed from the previous scan).

As an example... I have been running the SBP-2 driver in an embedded system
(on a 2.0 based Linux kernel) where we require automatic detection,
scanning, and mounting/unmounting of IEEE-1394 SBP-2 storage devices. We
added to the scsi host template functions allowing the equivalent of
add-single-device/remove-single-device to be called from the SBP-2 driver
when necessary. These add/remove calls were made from the kernel thread
within the SBP-2 driver.

Issues discovered with add-single-device call from low-level driver (which
basically just does a scan_scsis):
- Need to protect against re-entrancy in the add-single-device call,
otherwise some of the partition information stuff can get mixed up.
- Need to deal with re-entrancy in the low-level driver. The
add-single-device call re-enters the SBP-2 driver to do the actual I/O
associated with the scan, so just have to be careful here.
- Other than that, worked as expected.

Issues discovered with remove-single-device call from low-level driver
(which tries to release device structures):
- This always fails if the device is mounted (because of scd->attached
count).
- For our "somewhat hacked" implementation (on our embedded 2.0 kernel), we
added code to the remove-single-device call to do a force unmount, clean-up
open files, and signal any processes with open file handles. Kinda messy.
=(

NOTE: There has been some talk about "pending remove" (e.g. callback or
something when usage count drops to zero). This sounds good for the
hot-unplug case... especially if a user process is notified of the removal
and can force unmount the device.   ;-)

Anyway, hope this helps.

Cheers,
--James











_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel