Of course, drivers don't _need_ usbcore to protect them from this race, they can handle it themselves.
But I see three things wrong with that comment, making me think it'dBut here's a case where I think it'd be wrong to use a semaphore. Some sort of shared lock for routine use, with "unbind driver from interface" processing always getting it in exclusive mode, is more the right idea ...Upon first consideration I'd have thought so, but on second thought I found no use for a driver sending concurrent synchronous messages to an interface.
be even more wrong to use a semaphore there.
- They wouldn't be concurrent, they'd be sequential ... there's a queue,
nobody's going to mix packets from one urb up with those from the next.
The queue is in the HCD, not imposed through the scheduler. Ordering
of requests must necessarily be imposed by drivers, if it ever matters.
- And some drivers _do_ use async control messages, which would stop
working if you added a "synchronize to semaphore" requirement (since
issuing them in_interrupt would need to fail if the queue isn't empty,
rather than just appending to the queue).
- Plus, there's no requirement for drivers on different interfaces to
synchronize with each other to make control requests; all of them
could quite reasonably decide to issue control requests related to
their resources at the same time (on smp anyway).
Heck, there are even cases where different threads of a driver talking
to one interface might end up wanting to submit control requests at
the "same" time.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
