> On Sun, 7 Dec 2003, Oliver Neukum wrote:
>
> > More than that. New submissions of that URB must fail, or the newly
> > submitted URB unlinked, if the completion handler has won the race.
>
> My patch does this (submissions made before the synchronous unlink returns
> will fail).
I've changed my mind on this. Outright failure is a change of semantics.
It is not needed. Simply set a flag in this case and return success.
After the completion handler has returned, check the flag and recall it
with the error code for synchronous unlink in urb->status.
[..]
> > But that's not really an issue. All you need to do is to spin on a running
> > completion handler. After that either the completion handler has run,
> > which means the assumption drivers make is safe to make, or you
> > can unlink the newly submitted urb.
> > Not quite so trivial to implement without races, but there are _no_
> > changes to existing semantics.
>
> You're correct that this can be done by writing the driver appropriately.
> My point is that a lot of drivers would need to be changed, and it's
> easier to change the core and alter the semantics of the API.
Yes. That's the point. The essential point here is that usb_unlink_urb()
has to wait for the completion handler. The rest is sugar coating.
As I have pointed out you can do it with zero change to the API.
[..]
> On Mon, 8 Dec 2003, David Brownell wrote:
>
> > But if usbcore were to get changed, why not change it
> > to have a usb_urb_begone() call that MUST (eventually)
> > be used for all synchronous unlinks? That's a better
> > long-term approach IMO.
>
> I like that idea. In fact, why not make usb_unlink_urb() be purely async?
Shouldn't the common case of synchronous unlink be made simple?
> Another important area where better synchronization is needed in the core
> is submission/unlinking. An URB should be either:
>
> idle (not used at all or just beginning the submission process
> but not yet linked by the HCD),
> in progress (linked by the HCD, no errors encountered yet, not
> unlinked, not completed),
> or finishing up (error, unlink, or in completion handler).
>
> These state changes should be protected by urb->lock. But they aren't,
> and we currently can't distinguish between idle and finishing up.
>
> My proposal would make thise categories reliably detectable:
>
> idle: urb->usage_count == 0,
> in progress: urb->usage_count > 0 and urb->status = -EINPROGRESS,
> finishing up: urb->usage_count > 0 and
> urb->status != -EINPROGRESS.
>
What exactly does this buy?
usb_submit_urb() and usb_unlink_urb() don't change their behaviour based
on this states #1 and #3, except for usb_unlink_urb() waiting for a transition
out of #3
> All right. I was hoping to stir up a little discussion, and apparently I
> succeeded. It would be nice to arrive at a consensus regarding a few key
> points:
>
> Should the core change to prevent resubmission of URBs under
> certain circumstances?
>
> Should URB state tracking be more reliable?
>
> Should we try to fix the existing synchronous unlinking problem
> by auditing drivers or by altering the core to make it match more
> closely the drivers' preconceptions? Should we change them both
> a little?
No to the third option. Either go through all drivers _or_ change the core.
Not both.
Having seperate operations for synchronous and asynchronous unlinking
is independent from that and a good idea, but 2.7 stuff.
Regards
Oliver
-------------------------------------------------------
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
