> It seems to me that the distinction between interrupt transfers and bulk > transfers is somewhat artificial.
If you ignore bandwidth and other resource allocation issues, yes. But those are very real issues in many systems. "On the wire" you don't see much difference, except that there are parts of the frame that no interrupt transfer will ever appear in (parts not reserved for periodic transfers). > Despite advice to the contrary I find that a usb_bulk_msg seems to be able > to get a packet through an interrupt endpoint no hassles (on my target > platform, OHCI). That depends on the HC to reinitialize per-endpoint data structures on every call. For high speed devices (EHCI) that's not the best way to go. > I realise that this might not be portable. If so, why do we not have a > usb_irq_msg function/macro? Would this be somewhat easier than going > through the steps a-f below? Is this sort of request so uncommon that we > shouldn't abstract it into some sort of easier process? Well, I've never yet missed having an "interrupt that's not really and interrupt" facility, although that does seem to be what the "usbfs" code expects ... it doesn't actually have a fast way to pass any kind of periodic transfer through to userspace. On the other hand, it could be done and I suspect someone would want it. Though (a-f) is an excessively complex scheme, and I'd rather not see that implementation show up much. My main concern here is twofold: (a) there's a conceptual problem with INTR-OUT, and (b) the portability issue that makes the simple unlink-in-completion paradigm not work. What I _have_ heard people want relates to the INTR-OUT problem. - Dave
intr.c
Description: Binary data
