Re: SCSI Patches - mostly on/off-line stuff

[Bob Frey <bfrey@turbolinux.com.cn>]

On Thu, Jan 18, 2001 at 12:03:24PM -0500, Venkatesh Ramamurthy wrote:
> 	[Venkat] I agree that bus rescan is a better way. If the SCSI
> devices are connected though a SAF_TE processor then  we can poll the SCSI
> Bus frequently, as the SAF_TE knows about addition and detection.

Polling is not practical, because for some bus changes the kernel must
know immediately of the change and start using a new bus configuration -
for example in 1394 if the root device bus location has changed. Also the
user expects to see a 1394 device appear immediately after it is attached.
So the rescan for 1394 must be event driven.

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).

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 - ?

-- 
Bob Frey
bfrey@turbolinux.com.cn

_______________________________________________
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