Re: 2.6.9 USB storage problems

[Bill Davidsen]

On Thu, 4 Nov 2004, Pete Zaitcev wrote:

> On Wed, 03 Nov 2004 17:02:43 -0500, Bill Davidsen <davidsen@xxxxxxx> wrote:
> 
> > I just got information on this in another thread, in case you didn't see 
> > my note there, is this behaviour a bug, design choice, or unavoidable 
> > hardware issue? I can turn it off now, but I'm supposed to be getting a 
> > flash key thing to test, which is why I turned it on in the first place.
> 
> The explanation may be a little long.

Thank you for taking the time to make it! I now understand the problem
not only well enough to avoid it, but to ask another question below.
> 
> On most distributions, drivers are loaded with hotplug. Nobody, and I do
> mean it, for all practical reasons nobody loads their drivers from
> /etc/rc.d/rc.local anymore. (Side note: it is possible to load ub from
> /etc/modprobe.conf, but not usb-storage, because of too many layers
> between a block device and usb-storage: an open is a non-event there)
> 
> The hotplug is controlled by match lists, generated from C source (indirectly;
> actually from object files, compiled from C source). This way, what is loaded
> by hotplug would match what is present if same things were linked in, among
> other things. The hotplug has no preference mechanism aside from hand-editing
> those match lists. They have to be non-conflicting.
> 
> Given the above, it's hurtful to allow drivers to conflict, so such conflicts
> are rare. I know of bcm5700 vs. tg3, eepro100 vs. e100, 812x vs 8130too.
> AFAIK, in all such cases if one is configured, another cannot be configured
> and vice versa. The USB contains an exception, curiously enough. In 2.4
> kernels, it was possible to configure both uhci (ALT) and usb-uhci as
> modules. It was annoying; Red Hat resolved it by loading usb-uhci from
> /etc/rc.d/rc.sysinit (also marked in /etc/modules.conf, but that was
> just a tag for kudzu and other tools).
> 
> So, when ub is configured to service certain classes of devices, usb-storage
> relinquishes its control of them, resolving the conflict. This is assymmetric
> in its implementation, but it's an artefact; no implication is made about
> which driver is first among equals. In an ideal world we'd have something
> like CONFIG_USB_STORAGE_PREF with two values "ub" and "usb-storage", or such.
> 
> I thought about the coexistence between the two at some length, and it seems
> to me that the current scheme is the simplest workable scheme. I even thought
> it as "least confusing" until messages from Wolfgang and others made it clear
> that relationship between ub and usb-storage is not obvious enough to them.
> I'm always open to patches, too.

It would seem that wanting to use both flash keys and more common USB
devices would be the common case for those who use flash keys at all.
Would it be possible to have the regular USB drivers support the slow
devices, if only to the extent of handing them off as they do CD, NIC, or
disk? Or are these slow devices so unique that they are totally
incompatible with faster devices?

> 
> -- Pete
> 

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/