On Thursday 08 March 2007 7:33 am, Alan Stern wrote: > On Wed, 7 Mar 2007, Sarah Bailey wrote: > > > What transfer flags should usbfs2 expect userspace to set? > > > > I have opinions on most of the transfer flas, but I'm unsure about > > URB_NO_FSBR. ... > > In any case, URB_NO_FSBR is merely a minor optimization and it can safely > be ignored.
Should be ignored. Early versions of usbfs and usbutils had special UHCI debugging support, the rest of which is now gone. > > Also, could some USB gurus check my initial opinions on the other > > transfer flags: > > > > Userspace shouldn't be allowed to set URB_NO_TRANSFER_DMA_MAP and > > URB_NO_SETUP_DMA_MAP, since usbfs2 should set the policy on whether > > usbfs2 or the USB core does DMA mapping. > > Correct. Right. > > URB_NO_INTERRUPT also should be disallowed, since my code relies on > > the URB completion function being called for every URB. > > Probably true. Unless you want to support some mode in which userspace > submits a whole sequence of URBs for a single endpoint and gets notified > only when all of them are complete. In that case all of the URBs except > the last would have that flag set. Right. NO_INTERRUPT is an optimization that userspace can't use reliably ... in that scenario, it would be the kernel which is setting that flag, not userspace. > > URB_SHORT_NOT_OK is redundant, since userspace can detect a short read > > from the return value of the system call. Or is there a deeper reason > > for setting this flag? > > There is. It's there for handling the situation described above, where a > sequence of URBs is submitted at once. If one of them gets a short reply > then that flag will cause an error, so the remaining URBs can be unlinked > instead of blindly proceding. Of course, with delays between submitting one URB and the next, there's a race where that flag might not act as desired. I don't know whether that race has appeared or not ... > > > URB_ISOC_ASAP should be used automatically, unless the user specifies > > the start frame through an ioctl. > > Yes. However the ISO API has been under discussion for changes. See > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116233077631176&w=2 At this point, ASAP is the only scheduling policy that's generally available. I'd suggest you assume that, and not offer userspace any options for now ... > > URB_ZERO_PACKET should be allowed for buggy hardware. However, it seems > > like this should be a per-endpoint (or per-device) flag, rather than a > > per-URB flag. It would be nice if there was a file in sysfs so that > > there could be a udev rule to set this flag. > > No, URB_ZERO_PACKET is not intended for buggy hardware. It is meant for > situations where the host will send less data than the device expects to > receive. As such it has to be per-URB, not per-device or per-endpoint. Right. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
