Re: [RFC]extension of the anchor API

[Oliver Neukum <oneukum@suse.com>]

Am Montag, den 12.04.2021, 11:06 -0400 schrieb Alan Stern:
> On Mon, Apr 12, 2021 at 11:58:16AM +0200, Oliver Neukum wrote:

> > That presumes that the URBs will finish in order. I don't think such
> > an assumption can be made.
> 
> I don't understand -- I can't detect any such presumption.

OK, this shows that I am bad at explaining.
> 
> As far as I can tell, the only reason for maintaining the URBs in any 
> particular order on the anchor list is so that usb_kill_anchored_urbs 
> and usb_poison_anchored_urbs can kill them in reverse order of 
> submission.  THat's why the current code moves completed URBs to the end 
> of the list.

No longer strictly true, as the API has a call to submit everything
on an anchor, but I think it boils down to the same thing.

> If you keep a pointer to the most recently submitted URB, killing them 
> easy enough to do.  Start with that URB, then go backward through the 
> list (wrapping to the end when you reach the beginning of the list).

Yes, but that supposes that the next on the list has not been
resubmitted _before_ the one after it.

If you do not keep the list ordered, but in the initial order,
we can have the situation that A (happens most recently submitted)
is followed by B and C, but C was submitted before B.


> 
> The order in which the URBs complete doesn't matter, because trying to 
> unlink a completed URB won't cause any harm.

As long as it stays completed.

>   The only assumption here 
> is that URBs get submitted in the list's order (possibly circularly) -- 
> this should always be true.

I am afraid we cannot guarantee that. It might intuitively seem so,
but nothing guarantees that all URBs are going to the same endpoint.

	Regards
		Oliver