"legacy" usb stack fixes
julian at elischer.org
Sat Sep 13 04:09:52 UTC 2008
Scott Long wrote:
> On Fri, 12 Sep 2008, M. Warner Losh wrote:
>> In message: <48CAB37F.50002 at samsco.org>
>> Scott Long <scottl at samsco.org> writes:
>> : Scott Long wrote:
>> : > This is close to How Things Should Be. Each umass target having
>> its own
>> : > SIM and bus is indeed wrong, but I'm not sure if it's correct for all
>> : > USB controllers and buses to be under a single SIM. What would be
>> : > most correct is for each physical USB controller/bus instance to have
>> : > its own SIM instance. I don't know if it's better to do the
>> : > in ehci/ohci/uhci controller drivers or in usb bus driver; up in the
>> : > controller drivers is probably more correct. I don't like this
>> hack of
>> : > attaching stuff in a SYSINIT.
>> : >
>> : > Scott
>> : >
>> : >
>> : Now that I've thought some on it, I'll go one step further and say that
>> : registering a single SIM for multiple controller+bus instances in a
>> : SYSINIT will be highly undesirable thing to do. Since you have to
>> : register a lock with the CAM when you register the SIM, you'll wind up
>> : serializing all of the USB controllers under a single lock. Or you'll
>> : probably try something dangerous and tricky with dropping the new
>> : lock and picking up an individual lock, then swizzling locks in the
>> : completion and event paths, with the result being rather unsatisfying
>> : and unpleasant. So I know that you'll do what you believe is correct,
>> : but please take my advice on the matter anyways.
>> Yes. A SIM will serialize all operations, and the most logical place
>> for that is the computer <-> usb interface, which is the host
>> controller. So having one SIM per host controller would be the
>> optimal placement. Having one SIM per usb device doesn't result in
>> any more real parallelism because the host controller necessarily
>> serializes things because of how USB is defined...
> Correct. Another argument for having a SIM per controller/bus and not
> per target is that the SIM is responsible for managing all resources on a
> controller. USB is still a bus topology, and thus certain resources are
> finite and shared, be they bandwidth, arbitration, or concurrency.
> Granted, USB is simple enough that it doesn't give you much control over
> these resources, but having the SIM be at the target level gives the
> system even less control and visibility. If a future enhancement to USB
> grows the ability to do useful things like more concurrency, it'll be
> essential for the SIM to have a controller-wide view of this.
cam/umass used to have a SIM per USB bus but it got changed sometime
around 1999-2001 from memory. It was haled at the time as a great step
forward when each device got its own SIM but I could never work out why.
it did solve some problems though I forget what they where.
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current