From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Frey Date: Fri, 19 Jan 2001 03:57:40 +0000 Subject: Bus re-scanning should be event or manual triggered (no polling) 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 On Thu, Jan 18, 2001 at 09:16:27PM -0500, Venkatesh Ramamurthy wrote: > [Venkat] Bus reset is a very costly operation in SCSI. After doing a > SCSI BUS RESET all devices go to UNIT ATTENTION . All the devices need to > cleared from this condition. So in order to detect new devices are we going > to do a SCSI BUS RESET every now and then??? Since SCSI dos not support > target initiated event notification, we have no choice left. Some kernel > thread or a user daemon can initiate a bus scanning. There should be no periodic re-scanning and hence no host initiated bus reset to detect new devices. My point was that only if the host detects a parallel SCSI bus reset, should it automatically do a rescan. Some parallel SCSI implementations use the bus reset as a notification that the bus configuration has changed. For legacy busses like parallel SCSI that don't have an add-device interrupt the user should manually initiate a scan. This is what is done under Windows when you want to use a SCSI scanner that was not connected or was powered off at the time the system was booted. Go to device manager and press the refresh button. There is nothing wrong with this it just handles limitations of the parallel SCSI bus. For non-legacy busses like 1394, FC, USB that give an interrupt when a the bus configuration is changed re-scanning should be triggered by an interrupt. But please remove the idea of periodic re-scanning/polling - it wastes system and bus time and is prone to race conditions. Either the user should manually force a re-scan or the re-scan should be based on an automatic event supported by the bus that indicates the bus configuration may have changed. -- 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