From: Bob Frey <bfrey@turbolinux.com.cn>
To: linux-hotplug@vger.kernel.org
Subject: Bus re-scanning should be event or manual triggered (no polling)
Date: Fri, 19 Jan 2001 03:57:40 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-97987666023601@msgid-missing> (raw)
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
reply other threads:[~2001-01-19 3:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-97987666023601@msgid-missing \
--to=bfrey@turbolinux.com.cn \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).