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