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)?
>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.
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.
>> <snip>
>> queued non-resubmitting interrupt URBs would be very useful when
>> used by usbdevfs (i.e., userspace programs).
>
>Not to be too contrary here, but I'm not sure that's the right model to have
>for the periodic schedules. The HCDs seem like they should be populating
>the periodic schedule as interrupt/iso urbs are submitted, and then going
>away until either an IRQ signals periodic transactions completed, or until
>the urbs are descheduled/unlinked. No mucking around otherwise; that
>seems like it'd complicate transaction translators more than necessary.
I might not understand HCDs well enough to follow exactly what you're saying,
but I don't think the HCD should have to get any more involved (it should
handle URBs at the same points in time) than it currently is, if urb->resubmit
functionality is added.
>There are other models. Maybe SHM ring buffers, seen by userspace,
>could be how usbdevfs should deal with interrupt and iso transfers. Or
>maybe something else that can be scheduled once, then left alone.
Yes (actually this was my approach on the first usbdevfs interrupt patch, but in
a kludgy way), but the problem there is buffer overruns cause the (userspace)
app to lose data, while the device has no idea that data was lost. If the
device isn't getting polled, it will either buffer up the data or at least know
that data was lost. Plus using ring buffers or shared mem starts getting
significantly more complicated than the current model (which isn't necessarily
always a bad thing).
>The "API model" question came up on LKML recently;
I really need to read LKML more. :-)
>Johannes mentioned
>to Linus that USB periodic transfers (interrupt, iso) don't fit into the pipe/socket
>style model of bulk. (And maybe said as much about control urbs too ... I
>would have! :) I think it's fair to say that the "usbdevfs" API could be on
>the "rethink this" list for 2.5 ... maybe backported, maybe not.
Hmm...
--
Dan Streetman
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
