Am Donnerstag, 20. März 2003 17:03 schrieb Alan Stern:
> On Thu, 20 Mar 2003, Oliver Neukum wrote:
> > > were doing it, I'd not use the synchronous unlink call;
> > > "ought not" to matter, but we can be more sure than that.
> >
> > That's dangerous. We must have absolute confidence about whether
> > the message has gone over the wire or not.
> > Suppose it's a reset. We'd have a device at address zero without knowing
> > it. So this seems to be the easiest way.
>
> Correct me if this is wrong, but it's not so easy to tell whether or not a
> message has gone over the wire. With UHCI, it would be necessary to
> unlink it and then wait for the start of the next frame to be certain.
> And even then, for bulk OUT messages you face the possibility that the
> message was received correctly by the device but the ACK handshake was
> lost, so the host doesn't _know_ that the message was received.
Is this the case for control mesages as well?
I am not familiar with the controlers at hardware level, I must admit.
> In this case, it's very easy to use an asynchronous unlink rather than a
> synchronous one. All you have to do is wait for the struct completion
> again after the unlink call, with no timeout. Given that this whole
> matter revolves around updating the synchronous API interface, it's
> probably best not to use one synchronous call within the implementation of
> another.
Why? It seems obvious to me to use synchronous calls in a synchronous call.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
