On Tue, 9 Dec 2003, David Brownell wrote:
There is no such thing as a reentrant call to giveback_urb(); that'd mean that somehow the same URB got queued twice. If nothing else, the data structures don't support such a notion ... only one queue! :)
Oliver has now convinced me of that. But the reasons are fairly subtle! Consider dummy_hcd for example. There's no obvious reason preventing it
from calling giveback_urb directly from within the urb_dequeue routine.
I see what you mean, but it's not quite what I meant; we were probably talking past each other. Of course that routine can be "reentrant" in the classic sense, there's nothing preventing two HCDs from calling it at the same time from separate CPUs, for example.
What I meant was simpler: once _a given urb_ is given back to the driver, then it doesn't matter any more to usbcore. (Or at least to the HCDs...)
That routine only matters to HCDs, and the only history HCDs (should ever) need to care about is that related to current invocations ... reentrancy isn't much of an issue, except the potential lack of it.
But the "urb is idle" state is clearly a driver policy. All usbcore can know is whether it's queued for the endpoint. When an urb isn't queued, it doesn't (shouldn't!) care why ... there could be dozens of reasons why it's not queued (on an un-imaginative day). I can't see any reason why usbcore should even care about one of them.
There's one reason for the URB not being idle even though it's not queued
that the core _does_ know about (whether it cares or not): a completion
handler could be running. That lack in the two-state model was part of the reason the awkward "splice" technique had to be used.
Actually "splice" was created to simplify HCDs, so they'd only need to support the asynchronous (and two-state) model. And similarly to help ensure all HCDs implement the same semantics for synchronous calls ... previously that was hit-or-miss.
The basic idea is that the I/O requests for USB should be purely asynchronous, and synchronization policies should push up to higher levels. Ideally to device drivers, but usbcore can't avoid synchronizing things like enumeration, config changing, driver bind/unbind, and disconnect.
The only synchronization in the lowest level code (HCDs) should be with the hardware.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
