usb-storage: wait for device scanning before mounting root
in [Kernel]
|
Prev: usb-storage: wait for device scanning before mounting root
Next: [PATCH (RESEND)] ecryptfs: propagate key errors up at mount time
From: Stefan Richter on 19 Jun 2008 14:50 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. > > scsi_scan's API scsi_wait_scan's API > is geared towards drivers which create one or more > initiator port representations right up front before going on target > discovery, right? -- Stefan Richter -=====-==--- -==- =--== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 19 Jun 2008 14:50 > On Fri, Apr 25, 2008 at 03:11:23AM -0600, Matthew Wilcox wrote: >> The problem is that USB has one scsi_host per device (rather than, say, >> having one scsi_host and adding new devices to it as they're found on >> the USB bus). >> >> I'm certainly open to ideas of hooking into the mechanism -- it's just a >> list of completions after all. Something like this: [...] 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. scsi_scan's API is geared towards drivers which create one or more initiator port representations right up front before going on target discovery, right? -- Stefan Richter -=====-==--- -==- =--== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 19 Jun 2008 16:00 Matthew Wilcox wrote: > 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. > 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. [...] > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 19 Jun 2008 16:40 Matthew Wilcox wrote: > On Thu, Jun 19, 2008 at 09:54:06PM +0200, Stefan Richter wrote: >> 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. .... > Yes, I do see the problem. There's no way the SCSI core can know when > a driver has finished scanning, so I've punted to the driver to set its > own timeout here. This can of course (and frequently is) implemented in userspace, but requires an initrd. I'm not up to speed how scsi_wait_scan is put to use --- it can be used without initrd, can't it? > I know that new devices really can show up at any > time, but I think it's reasonable to say that if a machine is booted > with the same configuration as last time, the drives should show up with > the same names. I know that is not what you meant here, but...: They do show up with the same target identifiers and logical unit identifiers. The SCSI core doesn't pass the identifiers through to userland though. (Couldn't resist to go off-subject. Sorry.) -- Stefan Richter -=====-==--- -==- =--== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 19 Jun 2008 17:30
Let's face it, from the POV of several if not all transport layer drivers, the core API element Scsi_Host is just a superfluous appendage to the only interesting elements -- target and logical unit, or even logical unit alone. Matthew Wilcox wrote: > I would suggest that you want one 'channel' per usb endpoint. No, "channel" is meaningless. Friends don't let friends invent new meanings for "channel". -- Stefan Richter -=====-==--- -==- =--== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |