On Thursday, 17. May 2001 18:27, you wrote:
> On Wed, 16 May 2001, David Brownell wrote:
> >I'd prefer to get rid of the notion of one-shot interrupt transfers, for
> >consistency. That isn't the model for any other "periodic" transfers.
>
> I think better consistency would not come from removing one-shot
> interrupts, but instead resubmitting any URB based on a flag
> (urb->resubmit)? Resubmission could certainly be useful for Bulk
> transfers; e.g. if you want to read many MB of data. Could also be useful
> for iso. Probably not very useful for Control, but why create a special
> case (like has been done with resubmitting interrupts)?
Would there be any use of this feature that couldn't be achieved by
resubmission in the completion handler ? If not you are complicating the code
and cost everybody performance for the sake of a few users, IMHO.
> >Likewise, I prefer the simpler model of having only ONE way to make
> >an interrupt urb stop after submission: usb_urb_unlink(). Adding more
> >modes multiplies the code paths, and multiplies ways to create bugs ...
>
> I like simpler models too, but the problem with usb_urb_unlink() is you're
> effectively aborting the URB. It completes once, then you abort and it
> completes again with -ENOENT (I think). Thus, unless you're doing all
> processing inside the completion handler, the URB gets 'corrupted' after
> the completion. For usbdevfs, where it's read back by the userspace app
> well after the completion, only the error is seen.
So copy the URB. Why would one special user (usbdevfs) justify complicating
common code ? You need to make sure that your buffers are not overridden
while you still need the data anyway.
While we are at it, why is the selection of asynchronous vs. synchronous
unlink done in so strange a way ?
> Also, to perform a single-execution (one-shot) interrupt, 2x the work is
> done (it completes, is resubmitted, and is aborted). This causes
> significant overhead that really isn't necessary.
Which is the common case ?
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
