On Thu, 25 Jun 2009, Steve Calfee wrote: > Hi Alan, > > I think having a stop on short mechanism is a very good idea. If the > devio would just abort all pending transfers on the endpoint, on this > and all other urbs, we don't need a USBDEVFS_UNBLOCKEP call. The user > app knows the transfer is done, the next submission should start > another (possibly short transfer cancelled) IN urb. As Daniel pointed out, this won't work. Think about what happens when userspace submits several independent transfers (each of which might be broken up by libusb into multiple URBs), where a short packet should terminate only the current transfer, not all of them. > Lets be very clear about what a short transfer is. It is when a device > sends a less than maxpacket sized transfer. This is only meaningful > for int and bulk transfers (control too, but not relevant here). The > idea is, if your protocol is to just have a device send data until it > is "done", there needs to be a way to tell the receiver end the > transfer is done. So if your maxpacket size is 512, sending a packet > length 0 to 511 will say it is done. I don't think there is a current > standard class that uses a short packet transfer termination, but it > is useful in many custom applications. It is used in practice by many mass-storage devices. The spec requires the bulk-IN endpoint to be halted following a short packet, so that either the short packet or a STALL could cause termination, but many devices don't bother. > For lower overhead and higher transfer rates, userspace often asks for > multiple packets. There is the current arbitrary maximum xfer size of > 16*1024 bytes per urb. However, nothing stops an app from asking for 4 > urbs of 16K and then waiting. It think that now the short packet will > end the urb, but what of the other pending urbs? Alan's suggestion > will fix that. The problem is that sometimes those other pending URBs should be aborted and sometimes they shouldn't be. We could complicate the scheme by telling usbfs which ones to terminate. But it might be easier to take Daniel's suggestion and let the kernel, not libusb, do the splitting up. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
