Matthew Wilcox wrote:
quoted text
> On Thu, Jun 19, 2008 at 08:39:38PM +0200, Stefan Richter wrote:
>> The problem is AFAIU not exactly how many Scsi_Host instances (initiator 
>> port representations, or something remotely related to that) are 
>> instantiated, but rather _when_ they are instantiated.  On multi 
>> protocol buses or networks like USB and FireWire, it makes sense to 
>> create the SCSI initiator port representation when we discovered that 
>> there are actually SCSI targets on the bus or network.
> 
> I'm not convinced of that.

Drivers like usb-storage and sbp2 are high-level drivers (protocol
drivers) on top of driver stacks.  They a priori talk to struct device
instances which represent subunits on "external" devices; they don't
have much business with the local host controller device.  For them,
"SCSI initiator port" is a rather hazy and, in the implementation,
uninteresting concept.  (That's how it is with sbp2; I'm only guessing
how it is with usb-storage.)

However, there are several ways to accomplish the same thing in the
implementation.  I heard there were more constraints under Linux 2.4;
some current implementation details may just be legacy.

quoted text
> Why shouldn't we create one scsi host for
> all USB scsi devices?

Or one for each USB HCD.

I thought about that for FireWire but never started to actually try it
out.  Parent-child relationships of struct devices would be different
from what we have today.

[...]
quoted text
> The mail that I just pinged described a way to enhance the
> API -- letting you tell scsi "I've started scanning, save me a place in
> the queue" and "I've finished scanning, hook me up".

When would be the right time to say "I've started scanning"?  SCSI
transport driver initialization?  Or end of USB/FireWire/... HCD
registration?

When to say "I've finished scanning"? --- I think the answer is:  When
(a) probing of a configurable number of SCSI targets or logical units
was finished or (b) a configurable timeout occurs, whatever of the two
happens first.

(Explanation, if one is necessary:  SCSI targets may pop out of the
woods any time; it is impossible to say "from this moment on there won't
show up any new ones anymore".  This is just as true for cold boot and
warm boot as it is for subsequent operation.)
-- 
Stefan Richter
-=====-==--- -==- =--==
http://arcgraph.de/sr/
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/