David:

I had an idea this morning.

We've discussed in the past that the notion of unlinking a single URB is
unnatural.  When a driver has multiple URBs queued for an endpoint it will
always want to unlink all of them together; it will never want to unlink
only some -- that wouldn't make any sense.  Furthermore it's a lot easier
for HCDs to clear out all the URBs queued for an endpoint than to remove
just one of them.

The fly in the ointment is endpoint-0.  It's different from all the other
endpoints because any other endpoint will be managed solely by the
device's driver.  By contrast, multiple drivers are allowed to send URBs
to ep0.  When one of them unlinks an URB it should not interfere with any
of the others.

Now consider this.  Normally a driver will want to send only one URB to
ep0 at a time, it won't try to queue a lot of URBs.  (There might be
occasional counterexamples, but they will be relatively rare.)  So here's
what we can do:

        The hcd glue layer will maintain its own URB queue for each
        device's ep0 (actually it already does this).  It will only
        send one URB from this queue down to the HCD at a time.

        Now that the HCD's queue for ep0 never contains more than one
        URB, we can safely re-implement dequeuing in the HCD to make it 
        cancel all the URBs queued for an endpoint.  The API can remain 
        the same for now, although eventually (2.7?) we may want to change 
        it.

The overall effect is that usb_unlink_urb and usb_kill_urb will now unlink
all the URBs queued for the endpoint used by the argument URB, unless that
endpoint is ep0.  This shouldn't matter to drivers since they were going
to unlink all those other URBs anyway.

The business about having the glue layer submit only one URB at a time for 
ep0 might slow down some transfers, but not very many I think.  That's 
because there are very few places where drivers queue more than one URB 
for ep0 at a time.  Since the ep0 queue will almost always be empty when 
an URB is submitted, there won't be much additional delay.

Alan Stern



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to