From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Goodwin Date: Sat, 20 Jan 2001 22:55:56 +0000 Subject: RE: SCSI Patches - mostly on/off-line stuff (SBP-2 hot-plug comme Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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