From: Matthew Wilcox <matthew@wil.cx>
To: Arjan van de Ven <arjan@infradead.org>,
linux-scsi@vger.kernel.org,
Stefan Richter <stefanr@s5r6.in-berlin.de>,
linux-hotplug-devel@lists.sourceforge.net,
Patrick Mansfield <patmans@us.ibm.com>,
"Alexander E. Patrakov" <patrakov@ums.usu.ru>,
James Bottomley <James.Bottomley@SteelEye.com>
Subject: Re: Asynchronous scsi scanning, version 9
Date: Mon, 26 Jun 2006 15:18:28 +0000 [thread overview]
Message-ID: <20060626151828.GH1608@parisc-linux.org> (raw)
In-Reply-To: <20060626144442.GA13319@one-eyed-alien.net>
On Mon, Jun 26, 2006 at 07:44:42AM -0700, Matthew Dharm wrote:
> On Mon, Jun 26, 2006 at 06:40:01AM -0600, Matthew Wilcox wrote:
> > I'm not 100% sure what the problem is with USB. If it's that we may not
> > have discovered all the USB devices currently plugged in, then I think
> > we need to change the way USB works to use one Scsi_Host for all USB
> > storage devices, and then make each device either its own target or its
> > own channel (probably the former; the latter is less well-tested code).
>
> There are a couple of things which make this difficult for USB.
>
> First, some (many?) USB devices need to be left alone for several seconds
> after attachment in order to allow them to initialize to the point where
> they are usable.
That's OK. Once we know they're there, we can reserve their place
and delay until they're ready to go.
> Second, depending on how many hubs are between the host and target, the
> time-to-discover the device is highly variable.
Can, or does, USB keep track of hub discovery, and hence know whether
or not it's completed USB discovery?
> Third, once discovered the device may still take a long time to be "ready".
> Think of this as a slow spin-up time. This is different from my first
> point in that the device can actually accept commands, but all commands
> will fail with some sort of not-ready type error.
That's OK too.
> As for using one Scsi_Host... there are several usb-storage devices which
> attach to an entire SCSI bus (not just a single target), so can't make each
> device it's own target.
Oh. My fault for reading the comment rather than the code.
/* reject if target != 0 or if LUN is higher than
* the maximum known LUN
*/
else if (us->srb->device->id &&
!(us->flags & US_FL_SCM_MULT_TARG)) {
Do these devices stick to occupying only target IDs from 0-7? If not,
you may wish to increase ->max_id for those devices. I think it'd be worth
exporting scsi_scan_channel() from the midlayer (and rearranging it to have
__scsi_scan_channel() as was done with __scsi_scan_target) for USB's benefit.
> Also, at the time this was all written it wasn't
> possible to dynamically remove (with any stability) individual targets or
> channels. Perhaps that has changed?
It's definitely possible to remove individual targets dynamically now;
Fibre Channel has sorted that out (and will complain loudly if it breaks).
The scsi core doesn't really have a channel object; channel is just an integer
that describes a path to a target. So I think there should be no problem in
converting USB to have one host and many channels.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2006-06-26 15:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060511143352.GI12272@parisc-linux.org>
[not found] ` <20060518172258.GL1604@parisc-linux.org>
[not found] ` <20060529031915.GB23405@parisc-linux.org>
[not found] ` <447AB2F5.2000700@s5r6.in-berlin.de>
[not found] ` <20060529130515.GE23405@parisc-linux.org>
2006-05-31 23:21 ` Asynchronous scsi scanning, version 9 Patrick Mansfield
2006-06-01 12:22 ` Kay Sievers
2006-10-26 19:53 ` maximilian attems
2006-06-01 13:14 ` Alexander E. Patrakov
2006-06-01 13:21 ` maximilian attems
2006-06-01 13:23 ` Matthew Wilcox
2006-06-01 13:26 ` Alexander E. Patrakov
2006-06-01 14:00 ` Arjan van de Ven
2006-06-25 21:15 ` James Bottomley
2006-06-25 22:46 ` Matthew Wilcox
2006-06-26 8:24 ` Arjan van de Ven
2006-06-26 12:40 ` Matthew Wilcox
2006-06-26 12:59 ` Arjan van de Ven
2006-06-26 16:03 ` Greg KH
2006-06-26 14:44 ` Matthew Dharm
2006-06-26 15:18 ` Matthew Wilcox [this message]
2006-06-26 15:44 ` James Bottomley
2006-06-26 16:02 ` Greg KH
2006-06-26 21:08 ` Matthew Dharm
2006-06-26 22:15 ` Matthew Wilcox
2006-06-26 18:55 ` [SPAM] " Doug Ledford
2006-06-26 21:04 ` Matthew Dharm
2006-06-26 21:20 ` Doug Ledford
2006-06-26 20:58 ` Linas Vepstas
2006-06-26 21:14 ` James Bottomley
2006-06-26 21:21 ` Linas Vepstas
2006-06-26 21:41 ` James Bottomley
2006-06-28 7:52 ` Hannes Reinecke
2006-06-28 16:03 ` James Bottomley
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=20060626151828.GH1608@parisc-linux.org \
--to=matthew@wil.cx \
--cc=James.Bottomley@SteelEye.com \
--cc=arjan@infradead.org \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.com \
--cc=patrakov@ums.usu.ru \
--cc=stefanr@s5r6.in-berlin.de \
/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).