> > > All of these exceptions are one of the reasons I dislike the current
> > > (2.4) URB interface.
> >
> > I'm not entirely sure what you mean by that ... although I've begun to
> > dislike "automagic resubmit" more. The ISO ring stuff is particularly
> > annoying, there's no clean way to report some errors. And it's very
> > awkward for INTR-OUT transfers.
> >
> > I suspect that what you mean is at least that you'd like to see a simpler
> > model for periodic URBs ... with no "automagic resubmit", but with each
> > type of URB being queuable in the HCD. That'd likely make sense to
> > me as a 2.5 change, once the bandwidth reservation issues get worked.
> > (Reserve at set_config/set_interface time?? :)
>
> Yeah, that's pretty much what I meant. The URB interface pretends that
> everything is the same (one entry point, usb_submit_urb) but all of the
> different URB's behave differently. It's very difficult to understand.
Hmm, that's true too. Lots of implicit state in those URBs, and HCDs
are always dis-entangling it ... got any desire to fix any of it (2.5 :)?
One direction that came to mind is stripping out most of what's now
in URBs, and making them each refer to a single "transfer". (Maybe
just wrappers for buffer, length, and a completion handler.) Then
have type-specific submit calls (vs type-specific URB fields), each
of which implied queueing (no resubmit) and might even queue
many (related) transfers at a time.
- control ... a transfer for SETUP, an optional one for its DATA
- bulk ... just one transfer (N packets)
- intr ... like bulk, but adds a scheduling interval
- iso ... like intr (no iso_packet_desc)
Done right, I could imagine something very similar working on the device
side (and for "USB on-the-go", both device and host sides).
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
