Re: transfer flags policy

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel