Re: "legacy" usb stack fixes

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 
>> the
>> : > 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 
>> attachment
>> : > 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 
>> global
>> : 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.


> 
> Scott
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"