> I see that you wanted to make the USB API as simple as possible for driver > programmers. This is a good thing. In 2.4.x, all endpoints with reservation > (INT and ISO) have only constant sizes. For INT OUT endpoints, this was > not acceptable because there are devices with uses variable data block length.
Actually even for INT-OUT the packet size (hence bandwidth requirement) is fixed ... it's not an OS issue, it's a USB issue. A 2.4 issue here was the arbitrary restriction that interrupt transfers were packetized by the device driver, unlike all other non-ISO transfers. You couldn't just issue a 97 byte INT-OUT (or INT-IN). Re "as simple as possible", maybe so: almost every special case or arbitrary restriction in the API needs replication in at least three host controller drivers and several of the dozen in-kernel drivers, and is magnified exponentially in developer confusion and bugs. > Will the 2.6.x API be better for device driver writers? Most of the problem > solvers are "not merged in", as you say. What about the upcoming 2.5.x > feature freeze? I wouldn't say "most" of the problem solvers aren't yet merged in. You just used a list that focussed on ones in that awkward category. Likely there needs to be a list of all the things that have already changed, so you (and other skeptics :) can see that. As for the feature freeze, I think that if we get the UHCI code to treat interrupt transfers just like bulk (which happens to sit in the periodic schedule), we'll be OK. That doesn't mean no changes after the 20th; maybe even that one could (Greg and Linus get to decide :), but I'd sure rather it were in sooner than later. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
